best practices for secret_handle and secret?

[Paul Crowley]

Brad Fitzpatrick wrote:
> On Wed, 8 Jun 2005, Paul Crowley wrote:
>>Don't the answers returned by LJ::get_secret() have expiry times?
> 
> No.  That's site-defined how long they stick around.  In fact LiveJournal
> has never purged ours:

Ah.  I was sort of basing everything on the assumption that these 
secrets did get purged, and that we could rely on them to be purged.  Or 
at least that when we had a handle for a server secret, we knew its 
expiry date and thus could check on its validity.

Since the handle for LJ::get_secret secrets is a time, we could just 
declare a lifespan for them and thus infer their expiry date.  But the 
interface that Net::OpenID::Server talks to must figure out these expiry 
dates somehow.

For my implementation, I envisage a cron job, creating a new secret 
every few hours and deleting all the ones that have expired.  I envisage 
a database table something like

create table bbm_SalesAttribution (
    id varchar(20) primary key not null,
    pool varchar(10) not null,
    secret varchar(20) not null,
    created datetime,
    expiry datetime
);

inserting a new secret into it every few hours with a cron job, and 
getting the most recently created secret when I need a secret.

> Wouldn't a client just have its own heuristics like replacing 3/4 of the
> way through, or up until 2 hours before expiration?

In order to work this out a consumer needs to know when the next secret 
is going to be created, which it can't know.  It wants to know this 
because it wants to use the longest-lasting secret available: the longer 
the secret lasts, the longer the logins created using it last.  And 
consumers are dumb.

> I was thinking the same thing last night.  I'll probably let people do
> either:  define callbacks or subclass.

ie the default implementations of the methods call the callbacks :-)
-- 
   __
\/ o\ Paul Crowley, paul at ciphergoth.org
/\__/ http://www.ciphergoth.org/