[Seaside] Tiny URL processing ala Seaside

[Nevin Pratt]

Avi Bryant wrote:

> (Sorry for the delay on the reply)
>
> On Jan 29, 2006, at 12:56 PM, Nevin Pratt wrote:
>
>> Hi All!
>>
>> I think we are all familiar with the service offered by http:// 
>> www.tinyurl.com, for transforming huge URL's into tiny ones.  I've  
>> been running a similar mechanism in my Seaside app for maybe half a  
>> year now.  For example, on my site, both of the following URL's do  
>> the same thing:
>>
>>   http://www.bountifulbaby.com?tiny=100
>>
>>               and
>>
>>   http://www.bountifulbaby.com/seaside/index/birthingsupplies? 
>> searchstring=1007&searchtype=items&searchall=f
>>
>> If you try both of the above URL's, you will see that the URL  
>> arguments "searchstring=1007&searchtype=items&searchall=f" (from  the 
>> second URL) are used by the Seaside component to prepopulate  the 
>> search panel.  The URL argument "tiny=100" will cause the  Seaside 
>> component to reference a dictionary, where the "100" is a  key, and 
>> "/seaside/index/birthingsupplies? 
>> searchstring=1007&searchtype=items&searchall=f" is the value.  So,  
>> the 100 is transformed into the bigger URL, which in turn is then  
>> looked at for arguments for populating the search panel.
>>
>> Using a dictionary in this manner, it is trivially easy to support  
>> tiny URL's.
>>
>> Should a mechanism like this be put into the general Squeak  
>> distribution?
>
>
> This strikes me at first glance as strangely circular.  The reason to  
> have named arguments in the query string in the first place is to  
> have bookmarks that can live longer than a single squeak image -  
> otherwise you could just use the opaque session/continuation ids.  So  
> you're replacing an opaque identifier that indexes into an in-image  
> Dictionary with meaningful, external identifiers, and then replacing  
> those with a different opaque identifier that indexes into an in- 
> image Dictionary?  Why not just clear away all the cruft and go back  
> to _s and _k, and make your sessions really long lived?
>
> Ok, there *is* a good answer to that, which is that sessions use a  
> lot more memory than your tiny-url dict does.  But it seems like we  
> might be able to solve that for this purpose without going through so  
> many lossy indirections.
>
> Avi


Seaside 2.3 doesn't have _s and _k in the URL.  I've just started 
playing with Seaside 2.5, and if not for that, I would be totally lost 
by what you mean with "go back to _s and _k".  But I think I see it now.

Anyway, you mentioned "memory" as the answer to your question.  Well, 
the answer (for Seaside 2.3) is actually four-fold:

   1. Long lived sessions eat memory very rapidly (eg, your answer).
   2. Long lived sessions compound security issues.
   3. Seaside 2.3 did not support bookmarkable URL's
   4. Short "easy-to-remember" URL's are nicer to the customer than long 
randomly encoded URL's :-)

I think the issues surrounding #1 above are relatively well-known to all 
of us, so I won't dwell on it further.

The issues surrounding #2 are when one user "hijacks" another user's 
session, which probably occurs most often because the first user emails 
their URL to the second user, without realizing they just handed over 
their session "keys to the kingdom" when they did that.  Shorter 
sessions reduce the risk of damage due to session hijacking.

Avi, at one time I remember you talking about explicitly tying the 
session to the IP address-- was that ever done?  If so, then hijacking 
risk is almost completely eliminated, regardless of session lifetime.

As for issue #3, long ago I came up with a relatively simple scheme for 
making a single Seaside 2.3 application have multiple entry points.  For 
example, the main entry point is, of course, the home page, accessed in 
the usual way:

   http://www.bountifulbaby.com

But if I instead wanted to start the application from within the 
supplies section of the website, this URL could be used:

   http://www.bountifulbaby.com/seaside/index/birthingsupplies

The only difference between the above two URL's, so far as Seaside is 
concerned, is a difference in what component becomes the first rendered 
component in the application.  In either case, once the application is 
begun by the user, from there it continues in the usual Seaside 
fashion.  Well, almost.  There is still one more (subtle) difference.  I 
also made changes that caused Seaside to ignore (and also preserve) 
anything in the URL between the "/seaside/" part of the URL and the 
session gobbly-de-gook at the end at the end of the URL.  Thus, with the 
second URL above, the '/index/birthingsupplies' portion of the URL stays 
in the URL throughout the Seaside session.  This makes it so that if the 
session ever expires, it faults back to the same URL as it began with, 
whatever that happened to be.

At the time I did this, Seaside had a real problem with bookmarkable 
URL's, and this scheme solved my need for bookmarkable URL's (the 
"birthingsupplies" component of the website is only one of many, many 
components that can be indexed into in this manner).  I understand that 
for Seaside 2.5 (and above), there have been great strides made in 
bookmarkable URL's, but care to give me a pointer on how to do it?

As for issue #4, it is a no-brainer.  If you want to be able to give a 
customer a seamingly static URL into a Seaside application, shorter is 
always better than longer.  Appending "?tiny=" and then some short 
number is about as short and clean as I could think of.  Doesn't matter 
if Seaside has to work a little harder to resolve it-- the important 
thing here is something easy for our customers.

In any case, Seaside 2.5 (and above) may change my thinking on a few things.

Nevin