[Seaside] Truly Opaque URLs

[Jimmie Houchin]

Lukas Renggli wrote:
>> http://www.seaside.st/about/examples/multicounter/sAuAnwVDpWPgxuITuEvuGsyu
> 
> 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?

It seems to me that the bookmarkable portion is the
http://www.seaside.st/about/examples/multicounter/

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

>> Could such a URL management also enable possibly a shorter URL? How long
>> (how many characters) does something like a BASE64 ID have to be to be
>> unique enough to identify the code running at that point in that image?
> 
> 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.

Why would a simple non-comprehensible UUID at the end of a URL make any
parameters easier to guess? Or how would it affect security. If there
are no parameters in the URL, how does this affect anything of the such?

../seaside/home/ABigBunchOfJibberish

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.

>> To me the more opaque and the shorter the opaque portion of the URL the
>> better. I think this can help reduce arguments against the ugly URLs in
>> Seaside. It won't eliminate the arguments, but if we can have RESTful
>> style URLs up to the opaque ID, then we can have much of the best of both.
> 
> I don't see a problem. You can already have that by using session
> cookies. Then you only have the _k parameter remaining. In some cases
> you can also get rid of _k (see www.cmsbox.ch for example), but I
> don't suggest that you try that.

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.



Mini-Rant, not aimed anybody in particular.
Especially Lukas whose email this a response to.


As I've attempted to express in all of my emails. Quite possibly poorly.

This is simply an idea that I thought might present a cleaner URL for
Seaside while maintaining all the benefits Seaside has. That is all.

I wasn't and am not declaring any major problem per se. I just
didn't/don't see the benefit of having stated, declared or known
parameters in the URL, beyond an ID which can take you back to the point
in the code you were operating upon.

It was a thought, an idea. Not an expression of a problem.

People regularly comment about ugly Seaside URLs. Yes, they are
developers. Who else do we expect to make comments on a developers list.

I've seen numerous posts here about how users don't care about URLs and
that URLs don't matter, etc. All in defense of a particular URL scheme.
Doesn't make sense to me. Oh well.

Mini-Rant over.

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

Jimmie