[Seaside] Advice on writing secure webapps from a scarred friend

[Avi Bryant]

On Tue, 30 Jul 2002, Tim Rowledge wrote:

> Avi Bryant <avi@beta4.com> is claimed by the authorities to have written:
>
> > No, if you were using basic auth there wouldn't be a form to enter the
> > user/password, the browser would pop up a special window.  See
> > IAAuthenticatedSession (this is what the /config app uses).
> Ah. You're right, I copied from the example class IAAuthPageSession. If
> it's not the right thing to use perhaps the IAAuthPage* classes should
> be removed to avoid confusion.

Not sure there is a "right" thing - just a matter of trade offs.

> I've replaced things with a version from IAAuthenticatedSession alright
> but I've lost two facilities in doing so. How can I make the popup login
> window have a more meaningful message? What is the best way to put
> timeouts on the session (I had been using the technique in
> IAAuthPageSession, but perhaps I should use an IAExpiringCache? Would
> this allow a re-login and continue as I had before?)

No, you'd lose the current position in the session.  As I said, there are
trade offs.

> I tried the hacked-up session id attack after the change and it does the
> same thing, reporting no such page state. Shouldn't the request session
> id be checked against the actual session id somewhere? Surely if someone
> has logged in and got a session id of '12345678' and edits it to
> '1345678' something should be deciding there is a problem?

So the concern isn't that someone will hijack somebody else's session, but
that they'll produce an error message?  This doesn't sound so bad.

But it does sound like there's a bug, namely, that you're seeing an error
when you put in an invalid session rather than just being redirected to a
new one.  This would be a problem in IAApplication>>sessionForRequest: -
I'll take a look at it later, I guess.