OpenID Libraries should be stateless

[Ryan Ernst]

I know about "dumb" mode and stateless operation.  The state that is
necessary for "smart" mode is the secret key shared between the relying
party and the openid server.  That is state preserved outside of the
session.

The yadis discovery state is stored in the session map simply as an object
reference.  This binds the application to a single machine if you use file
level session state instead of a table in your database (and then
replication becomes an issue).

What I am suggesting is the discovery manager stores its state in the
session map as a string (which is not bound to the machine where that
discovery manager object resides).  Then, the user can choose how to store
that information across their system (whether it be a session table, or get
parameters in the return uri).

Currently I have "hacked" this by creating a dictionary for the
Consumer.begin function and then using pickle to serialize the object and
pass it as a get parameter as described above.  This seems unnecessary if
the manager didn't assume the same machine would be handling the complete
step.

Ryan

On Feb 4, 2008 5:01 PM, Ryan Ernst <ryan at iernst.net> wrote:

> I know about "dumb" mode and stateless operation.  The state that is
> necessary for "smart" mode is the secret key shared between the relying
> party and the openid server.  That is state preserved outside of the
> session.
>
> The yadis discovery state is stored in the session map simply as an object
> reference.  This binds the application to a single machine if you use file
> level session state instead of a table in your database (and then
> replication becomes an issue).
>
> What I am suggesting is the discovery manager stores its state in the
> session map as a string (which is not bound to the machine where that
> discovery manager object resides).  Then, the user can choose how to store
> that information across their system (whether it be a session table, or get
> parameters in the return uri).
>
> Currently I have "hacked" this by creating a dictionary for the
> Consumer.begin function and then using pickle to serialize the object and
> pass it as a get parameter as described above.  This seems unnecessary if
> the manager didn't assume the same machine would be handling the complete
> step.
>
> Ryan
>
>
> On Feb 4, 2008 2:43 PM, Josh Hoyt <josh at janrain.com> wrote:
>
> > 2008/2/4 Ryan Ernst <ryan at citewire.com>:
> > > This weekend I started implementing OpenID on my site using the
> > > python-openid library.  In doing so I found that the library requires
> > > session state to be kept from consumer.begin() to consumer.complete().
> >  Why
> > > does the library need this session information?  And if the library
> > does
> > > really need the information, it should be able to save it as a
> > stateless
> > > string (not a python object which is bound to the server it was
> > created on),
> > > which can be encrypted (does it need to be?) and appended as get
> > parameters
> > > to the return_to uri.
> > >
> > > Is there any work being done for this? Would it be trivial or
> > non-trivial?
> >
> > It's possible to use the library in a completely stateless
> > configuration, but the user experience is worse: the discovery phase
> > has to happen twice instead of once, and there is an extra HTTP
> > request that is necessary to validate the response with the OpenID
> > provider, making authentication much slower.
> >
> > You can get around the double-discovery in many cases by adding a
> > signed encoding of the discovered information to the return_to URL in
> > the request. Previous versions of these libraries included this trick,
> > but it's rare these days for dynamic application to not have a
> > session. You can implement it fairly simply, but we didn't want to
> > deal with maintaining two ways to do it when one serves most people.
> > If you look in the consumer module, you can see that there is a
> > high-level interface that takes care of the session-related stuff.
> > Just create another implementation of it that manages the discovered
> > data in another way.
> >
> > If you don't mind the degradation of user experience, you can just
> > pass None as the store to the constructor of the Consumer object, and
> > everything will work (pokily.)
> >
> > Hope that helps,
> > j3h
> >
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.openidenabled.com
> > http://lists.openidenabled.com/mailman/listinfo/dev
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openidenabled.com/pipermail/dev/attachments/20080204/5d7e1bde/attachment.htm