Login form fails when entry is delayed

[Scott Battaglia]

We've been using this in production for years without issue.   As I've
previously stated its intended to prevent browsers that cache POST
statements from resubmitting them (its also part of the CAS spec) by using
the back button.  If you find the timeout period unacceptable, you have the
following options (okay its only two, lol):

1.  Increasing the timeout length of the session.
2.  Reconfiguring Spring Web Flow to store its information as part of the
request.

#2 is a simple change in the flow configuration in the cas-servlet.xml.  If
you do it, then you won't have the timeout issue, though you may lose the
ability to prevent re-POSTs  on older browsers (I tested IE6, FireFox,
Safari and Camino and wasn't able to reproduce the POST problem but I don't
have any older browsers).  Note, if you do opt for this you should add
<%@page session="false"%> to the top of the JSP pages so they don't create
any sessions (since you won't need them).  You should also make sure you
don't store anything sensitive in the Flow scope of Spring Web Flow unless
you encrypt your flow.

We're actually investigating #2 at Rutgers as part of our load testing of a
distributed ticket registry (as it removes the need to use sticky
sessions).    Is anyone familiar if newer browsers have the POST caching
issue?  If not, we may be able to make "Off" the default.  However, I
wouldn't want to do that if it introduced a potential security issue.

-Scott

On Feb 11, 2008 3:35 PM, dale77 <Dale.Ogilvie at trimble.co.nz> wrote:

>
> Scott,
>
> The behaviour does appear to be problematic. If I browse to the login
> page,
> get interrupted for a short period longer than the session timeout, then
> come back and type my valid credentials - nothing happens.
>
> This case, with no secure data entered into the form, followed by a
> shortish
> delay prior to actual credential entry, would seem to be quite common to
> me.
> The worst case here is that a user *might* assume that they entered the
> wrong password the first time, and try another, before getting on to
> support
> to say they can't log on.
>
> It would definitely be nicer if the initial logon screen wasn't so session
> dependent. Could you please explain a little more about why it has to be
> this way?
>
> Thanks
>
> Dale
>
>
> scott_battaglia wrote:
> >
> > There's no logic problem. The login process utilizes Spring Web Flow to
> > control the flow of the login process.  Spring Web Flow is used by
> default
> > in conjunction with session management to prevent you from re-submitting
> > credentials (in the case of a browser caching POST data).  We've kept
> the
> > default session relatively short to minimize the memory usage.
> >
> > If you are concerned, you can either extend the session timeout (thus
> > consuming more memory), or switch to the backing store which uses the
> > request object instead of the session object (this has security
> > implications).  I haven't been able to re-create the resubmitting POST
> > problem on newer browsers but I'm not sure which browsers are affected
> by
> > it.
> >
>
> --
> View this message in context:
> http://www.nabble.com/Login-form-fails-when-entry-is-delayed-tp15403686p15419997.html
> Sent from the CAS Users mailing list archive at Nabble.com.
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>



-- 
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080212/3e59fc19/attachment.html