[Seaside] Truly Opaque URLs

[Lukas Renggli]

> > Seaside 2.0 to 2.3 (or something around that version) had the IDs in
> > the URL, not in parameters. See www.squeaksource.com for example. That
> > makes it difficult to create bookmark-able URLs.
>
> How does it make it more difficult to create bookmarkable URLs?

Because it makes it more difficult to differentiate custom URL parts
and automatic generated ones. Moreover it makes it impossible to use
relative URLs.

> And everything after that points to the running code in the image.

Well, these are just objects that are referenced. _s references an
instance of WASession. _k references an object that responds to
#value:.

> > You easily number them or use any other unique string to identify
> > them. See the references to the WAExternalID class.
> >
> > This would mean of course, that people would be even more tempted to
> > play with the parameters and you would loose the important security
> > aspects of your application. It would be ways much easier to guess the
> > parameters and go into a different session.
>
> I don't understand this.

_s and _k are cryptographically secure keys into a particular point of
a session. If you shorten these keys or use a deterministic way to
generate them, people will be able to guess the parameters and
potentially kidnap a session.

> It would seem to me that the only thing that would happen is what
> currently happens, they would be redirected to the app entry point with
> a new session ID in the URL.

Yes, this was the way it was implemented in Seaside 2.0. See
www.squeaksource.com.

> I am not an expert, but I'll guess that we have such embedded in the URL
> because cookies aren't always a viable solution. I don't know what all
> problems cookies present or not. But that is another discussion.

Seaside falls-back to normal behavior (and _s parameter in the URL) if
cookies are disabled on the client.

> My apologies to all. I guess I just don't get it.

I think I get it.

Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch