> Charles  wrote:
> > Maybe the better option would be to move the check to the rest of the
> > session handling code, where it could be run when enabled for that
session.
> > Any ideas on how to do this?
>
> I think you could also do it inside the application code.  For
> example, assuming you are using Quixote 2, add a _q_traverse method
> does whatever checking is desired.  Return an error page if access
> is not allowed.

Yes, I think this would be best.  I looked at the code that does the check
and then saw that it was literally one "if" statement.  Should be a snap to
insert that where the session is loaded, which would allow it to be enforced
on a per session basis.
>
> > Has anyone else come up with a good way to keep sessions secure short of
> > expiring them after a certain time?
>
> Could you explain what kind of attacks you are concerned about?

Primarily session id cookie hijacking... I realize that getting another
user's session cookie should already be sufficiently difficult by not
rendering malicious javascript submitted by users (via non-htmltext).  But
when the IP check is enforced with the session id, even a illegitimate
session id would not grant unauthorized access.  Unfortunately there are
legitimate cases where a user's IP changes mid session (AOL, proxy servers,
etc) that makes this check fail.  I hate to throw the whole thing out of the
window for those specific cases.  So in that case I figure that disabling
the IP check and enabling an aggressive session timeout would be the next
best thing.  Aggressive timeouts can be annoying for users, but in this case
it seems neccessary.  I was just wondering how other people dealt with this.

Thanks Neil!

-Charles