You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Anson Zeall <ze...@bigpond.net.au> on 2003/09/09 11:57:12 UTC

Implementing a Login procedure, but avoiding cookies/session

Hi,

    I would like to know if there is anyway I could avoid the use of Session
or cookies for a login procedure, but still keep track of the user's login
status?

From,


Anson





JSP Compilation - saving compiled JSPs to disk howto?

Posted by Duncan Frostick <df...@bmjgroup.com>.
(If this is received twice I apologise)

Hi all,

I'm hoping this is a simple question that only needs one config change, 
but I don't know. I need to configure tomcat so that when a JSP is 
compiled upon first request, the actual compiled file is saved to disk 
permanently and used by tomcat from the disk rather than stored and run 
only from memory. The reason this is needed is so that after a tomcat 
restart (which is needed quite regularly), all the JSPs don't need to be 
recompiled, which takes a long time on our large application. Of course, 
if the JSP source has changed, then it would need to recompile, but 
otherwise I'd like it to use a disk copy of the compiled JSP, saving the 
server recompiling upon a restart, thus saving our users a long time of 
waiting for the server to become responsive again.

Any help much appreciated,

Duncan Frostick


RE: Implementing a Login procedure, but avoiding cookies/session

Posted by Anson Zeall <ze...@bigpond.net.au>.
Thanks chris!!!! I think I know what to do now......thanks!! =)

-----Original Message-----
From: Christopher Williams [mailto:ccwilliams3@ntlworld.com]
Sent: Tuesday, September 09, 2003 9:53 PM
To: Tomcat Users List
Subject: Re: Implementing a Login procedure, but avoiding
cookies/session


Anson,

If cookies are disabled, Tomcat uses URL rewriting to store the session
ID. When you encode URLs you need to to use special methods to support
this feature.  These methods are defined in HttpServletResponse and are:
    String encodeURL(String url)
    String encodeRedirectURL(String url)

So, instead of calling:
    response.sendRedirect(url);
you should call:
    response.sendRedirect(response.encodeRedirectURL(url));

If the session ID is stored in a cookie, this call is a NOOP.

Does this make sense?  By the way, you may have noticed that some web
sites have a mysterious ";jsessionid=BASE64-encoded-gobbledygook" added
to the URLs when you browse them (try www.postoffice.co.uk for an
example).  This is URL-rewriting in action.  Importantly, the jsessionid
value is opaque. Unless you'd managed to spy on another user's session,
there is no useful change you could make to this value to enhance your
privileges on the web site.  The session IDs are long, random, unique
strings used (presumably) as the key to a hashtable.

Of course, there's nothing to stop you implementing a similar scheme
yourself, but there's no need.

Hope this is useful.

Chris.



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



Re: Implementing a Login procedure, but avoiding cookies/session

Posted by Christopher Williams <cc...@ntlworld.com>.
Anson,

If cookies are disabled, Tomcat uses URL rewriting to store the session ID.
When you encode URLs you need to to use special methods to support this
feature.  These methods are defined in HttpServletResponse and are:
    String encodeURL(String url)
    String encodeRedirectURL(String url)

So, instead of calling:
    response.sendRedirect(url);
you should call:
    response.sendRedirect(response.encodeRedirectURL(url));

If the session ID is stored in a cookie, this call is a NOOP.

Does this make sense?  By the way, you may have noticed that some web sites
have a mysterious ";jsessionid=BASE64-encoded-gobbledygook" added to the
URLs when you browse them (try www.postoffice.co.uk for an example).  This
is URL-rewriting in action.  Importantly, the jsessionid value is opaque.
Unless you'd managed to spy on another user's session, there is no useful
change you could make to this value to enhance your privileges on the web
site.  The session IDs are long, random, unique strings used (presumably) as
the key to a hashtable.

Of course, there's nothing to stop you implementing a similar scheme
yourself, but there's no need.

Hope this is useful.

Chris.



RE: Implementing a Login procedure, but avoiding cookies/session

Posted by Anson Zeall <ze...@bigpond.net.au>.
When you mean 'session' its using methods like HttpSession session =
req.getSession(true);? If yes...then...aren't they still using cookies?
'cause that's what I'm using. And when I test my app by turning off the
cookies....my app is just...screwed

-----Original Message-----
From: Christopher Williams [mailto:ccwilliams3@ntlworld.com]
Sent: Tuesday, September 09, 2003 8:17 PM
To: Tomcat Users List
Subject: Re: Implementing a Login procedure, but avoiding
cookies/session


Magic?  Actually, you could use URL-rewriting or hidden forms, but
anybody using your page could change the value from "0" to "1" to fool
your code into thinking they'd logged on.  They could also do the same
with a cookie if they reverse engineered your cookie data (which is not
hard).  Best to use the Session object as that's stored server side,
and, conveniently, goes away when the user does.



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org



Re: Implementing a Login procedure, but avoiding cookies/session

Posted by Christopher Williams <cc...@ntlworld.com>.
Magic?  Actually, you could use URL-rewriting or hidden forms, but anybody
using your page could change the value from "0" to "1" to fool your code
into thinking they'd logged on.  They could also do the same with a cookie
if they reverse engineered your cookie data (which is not hard).  Best to
use the Session object as that's stored server side, and, conveniently, goes
away when the user does.