You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Antonio Gallardo <ag...@agsoftware.dnsalias.com> on 2002/12/05 10:29:41 UTC
Re: [Authentication] - User with mixed Sessions
Christoph:
Many thanks for the help you provided. Today I will confirm if the problem
was related to the problem in the "multithreading" of Cocoon or if I have
a bug into my code.
If everything is fine I will try to turn on the proxy again to improve the
performance. Since there are no more than 40 users. I think this is not
urgent to turn the proxy on. But I think we need to know if Cocoon will
work or not with the proxy turned on.
As long as I reserched, the cookies must be enough to keep the track of
the users' sessions. On the page 303 of the book "Cocoon: Building XML
Applications" states:
"The default is usually to use cookies because the developer of the web
application does not need to do anything special to use them...."
To assure the authentication is the only one that creates sessions and I
am using also the XSP Session LogicSheet. I was also explicitly turned off
the generation of new sessions in my XSP pages with:
xmlns:xsp-session="http://apache.org/xsp/session/2.0" create-session="false">
Best regards,
Antonio Gallardo.
Christoph Gaffga dijo:
>> Where I can configure for all the pages the
>> response.setHeader("Cache-Control", "No-Cache");
>
> I'm using a filter for that:
>
> in my web.xml-file:
> <filter>
> <filter-name>ModifyRequest</filter-name>
>
> <filter-class>com.triplemind.asp.server.ModifyRequestFilter</filter-class>
> </filter>
> <filter-mapping>
> <filter-name>ModifyRequest</filter-name>
> <servlet-name>Cocoon2</servlet-name>
> </filter-mapping>
>
> And a short Filter-Class:
> package com.triplemind.asp.server;
> import javax.servlet.Filter;
> import javax.servlet.FilterChain;
> import javax.servlet.FilterConfig;
> import javax.servlet.ServletRequest;
> import javax.servlet.ServletResponse;
>
> public class ModifyRequest implements Filter {
> private FilterConfig filterConfig = null;
> public ModifyRequest() { }
> public void init(FilterConfig filterConfig) {
> this.filterConfig = filterConfig;
> }
> public void doFilter(ServletRequest request,
> ServletResponse response,
> FilterChain chain) {
> try {
> response.setHeader("Cache-Control", "No-Cache");
> chain.doFilter(request, response);
> } catch(Exception e) {
> e.printStackTrace();
> }
> }
> public void destroy() { }
> }
>
> hope, that helps.
> I put some more features in my ModfiyRequest, to change the Request-URL,
> and Cookies and put some more Header-Information, such as
> Expires-Headers.
>
> Christoph Gaffga
> cgaffga@triplemind.com
>
>
> ----- Original Message -----
> From: "Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
> To: <co...@xml.apache.org>
> Sent: Saturday, November 30, 2002 8:25 PM
> Subject: Re: [Authentication] - Generate javascript using XSP
>
>
>> Where I can configure for all the pages the
>>
>> response.setHeader("Cache-Control", "No-Cache");
>>
>> Can I put it into the header of the HTML in my XSL?
>>
>> Regards,
>>
>> Antonio Gallardo
>>
>> Christoph Gaffga dijo:
>> > Hi,
>> >
>> >> I think that this can be done because the proxy is returning a
>> cached page from another user. Because the request has the same URI
>> from every user (as long as I can see). The request URI does not
>> have info about sessions.
>> >
>> > If you are behind a proxy maybe you can configure it not to cache
>> urls at http://internalserver:8080/theapp/.
>> > Or it helps if you do
>> > response.setHeader("Cache-Control", "No-Cache");
>> >
>> > yours
>> > Christoph Gaffga
>> > cgaffga@triplemind.com
>> >
>> > ----- Original Message -----
>> > From: "Antonio Gallardo" <ag...@agsoftware.dnsalias.com>
>> > To: <co...@xml.apache.org>
>> > Sent: Saturday, November 30, 2002 9:32 AM
>> > Subject: [Authentication] - Generate javascript using XSP
>> >
>> >
>> >> Hi Cococoners!
>> >>
>> >> I am currently an application that is currently running on a test
>> mode with a small amount of users (20) in a Intranet environment.
>> With the following characteristics:
>> >>
>> >> The application is running behind a proxy.
>> >> The app use the authentication framework.
>> >> The app have a page called welcome that show the current user.
>> >>
>> >> I am currently having problem with session management:
>> >>
>> >> The users told me that sometimes when they are already
>> authenticated and request the welcome page, the response present
>> another user.
>> >>
>> >> The page is called with http://internalserver:8080/theapp/welcome
>> >>
>> >> I think that this can be done because the proxy is returning a
>> cached page from another user. Because the request has the same URI
>> from every user (as long as I can see). The request URI does not
>> have info about sessions. But I read in the book from Carsten and
>> Mathhew on page 303 (second paragraph from the end):
>> >>
>> >> "The default is usually to use cookies, because the developer of
>> the web application does not need to do anything special to use
>> them. ..."
>> >>
>> >> Please Dont let me wrong. I now that the problem is caused by me.
>> :-D
>> >>
>> >> The menu of the application is a static Javascript file served with
>> a reader. This file hs no info about sessions. Now I realized that
>> in order to "set" a session into the request I need to include a
>> parameter with the SessionID for every request. I does not include
>> it before because the quote above.
>> >>
>> >> With this scenario my questions is:
>> >>
>> >> How I can ensure that every request URI from the user will have the
>> SessionID included or use the default cookies?
>> >>
>> >> For me this is not a trivial question, because:
>> >>
>> >> I thinked first: "OK, I will generate the menu.js on ther fly using
>> XSP."
>> >>
>> >> But after think a while I realized that this issue will fall again
>> in the same category as the
>> http://internalserver:8080/theapp/welcome explained above. :-(
>> >>
>> >> Please tell me what can I do?
>> >>
>> >> I am currently thinking in calling the menu.js with the sessionID
>> too.
>> >>
>> >> This will work or there is another easier way to do that?
>> >>
>> >> Many thanks in advance,
>> >>
>> >> Antonio Gallardo.
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> Please check that your question has not already been answered in
>> the FAQ before posting.
>> <http://xml.apache.org/cocoon/faq/index.html>
>> >>
>> >> To unsubscribe, e-mail:
>> <co...@xml.apache.org> For additional commands,
>> e-mail: <co...@xml.apache.org>
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> Please check that your question has not already been answered in
>> the FAQ before posting.
>> <http://xml.apache.org/cocoon/faq/index.html>
>> >
>> > To unsubscribe, e-mail:
>> <co...@xml.apache.org> For additional commands,
>> e-mail: <co...@xml.apache.org>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> Please check that your question has not already been answered in the
>> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>>
>> To unsubscribe, e-mail: <co...@xml.apache.org>
>> For additional commands, e-mail: <co...@xml.apache.org>
>
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>