This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Putting some concerns to REST?
Feed Title: Avi Bryant
Feed URL: http://smallthought.com/avi/?feed=rss2
Feed Description: HREF Considered Harmful
Charles Miller is concerned about URLs in Seaside and similar frameworks:
In the oft-cited Smalltalk continuation framework Seaside and its Ruby port Borges, all links are anonymous callbacks, and thus are meaningless, transient strings bunged on the end of the application's base URL.
As a random example, take web stores. I can copy an Amazon URL from my location bar, paste it to a friend in e-mail or an IM, and that friend will see exactly the same product that I'm looking at. Whenever I go to a site, find something I want someone else to look at, paste them the URL and discover they've encountered a "This is not your session" message, I make a strong mental note to avoid that site in the future.
He's basing these comments at least in part on this post of mine:
People often complain about having "meaningless" numbers in the URLs, but they enable a level of abstraction over HTTP that wouldn't otherwise be possible.
Let me be more explicit. To enable the abstraction I'm talking about, you absolutely do need the meaningless numbers in the URL, and people do complain about this because it makes the URLs "ugly". But Charles was assuming my statement was also implying something that it actually isn't: that you can't have meaningful segments in the URL. That's not true in Seaside.
The way it works is this. At any point in a Seaside program, you can specify additional path elements that you wish to appear in the URL. These will get inserted in front of the session key, so that instead of
It doesn't matter how long this extra information is because the special /@ string identifies where the session key starts.
Now, as long as that session key is valid, the extra segments will be ignored: they provide a rough pointer to the current position in the app, but the session and continuation IDs provide a more exact position, so they will be used instead. However, if you send the link to a friend1, or bookmark it and come back once the session has expired, your application will get a chance to look at the meaningful part of the URL and construct a new session that starts at the appropriate point. This is extra work %C2%96 Seaside doesn't force you to do it if your users don't need it %C2%96 but it's explicitly supported in the framework for those that do.
Once place you can see this in action is at www.tric.nl, which uses a Seaside-based Wiki written by Cees de Groot. To prove my point, I've used a deep link to the Smalltalk page.
1Out of the box, Seaside doesn't protect you from "session hijacking" if you send a link to someone else - if you want to let someone else in on your session, feel free. Depending on the nature of the app, and the method you use for authentication, this may be fine. However, if this was something you needed, it would be very easy to add a cookie or IP based check that ignored the session key section of the URL if the session wasn't created on that computer.
Previous Topic
