[Seaside] REST, bookmarkable URL's (and authentication)

[Stephen Pair]

Cees wrote:
> <idea>
> Seaside interprets the opaque info, and if it points to a
> session that's gone, it uses the mount path to redirect to 
> the 'entry page' of the component. 
> </idea>
> 
> So I have a domain 'resource'. I 'mount' it at
> '/domain/foobar.com'. Now, when I go to '/domain/foobar.com', 
> Seaside redirects me to 
> '/domain/foobar.com?sess=SDFKJNEWIUFSKDFHksfZXC&step=1'. When 
> I use that thing half a year later, I get redirected to the 
> same point, but with a fresh session, and possibly a password box. 
> 
> I think that would combine best of both worlds.

This sounds so easy, there must be something wrong with it but I can't
think of anything at the moment.  The URL is ugly, but it is
bookmarkable (maybe the ugliness is why I didn't like this solution
before).  Also, the bookmarked page will change over time (when the
session expires).  Those two negatives are about all I can think of.  

The only thing Seaside cares about in these URLs is the session and step
info, unless the session has expired, in which case it begins a new
session and redirects to the URL for the new session (at which point you
could also use other query parameters from the URL).  When starting a
new session, it should also be careful to preserve any query parameters
other than "sess" and "step" in the new session's URL.

Sounds to me like this would work and wouldn't require any frames or
'bookmark me' silliness.  I think the benefits out-weith the URL
ugliness (which is the only downside I can think of) and the fact that
the bookmark's target changes when the session expires.

<authentication>
The other thing I'd like to solve is the authentication issue...is there
a simple way to provide automated interfaces (such as wget) the ability
to authenticate a user such that wget can access resources that cannot
be accessed anonymously?  One way is to pass the authentication info as
query parameters (i.e. '/domain/foobar.com?user=joe&pass=secret'), but
that is not very secure.  Is there a better way that is simple and more
secure?  I suppose I could restrict such automated logins to an SSL
connection.
</authentication>

- Stephen