best practices for secret_handle and secret?
paul at ciphergoth.org
Wed Jun 8 11:06:11 PDT 2005
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
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,
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
More information about the yadis