best practices for secret_handle and secret?

[Brad Fitzpatrick]

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:

select from_unixtime(min(stime)) from secrets;
+---------------------------+
| from_unixtime(min(stime)) |
+---------------------------+
| 2000-01-01 00:00:00       |
+---------------------------+
1 row in set (0.00 sec)

mysql> select count(*) from secrets;
+----------+
| count(*) |
+----------+
|    13568 |
+----------+
1 row in set (0.03 sec)


> I forgot to add a useful field to the get_authkey reply structure:
> "replace_after".  This is a time before the expiry time when you would
> be wise to replace the secret that you're using; it helps ensure that
> consumers use long-lifespan secrets, and thus can treat the tokens they
> receive as valid for longer.  There are no MUST bits in the standard
> connected to this field, only SHOULDs.

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

> Net::OpenID::Server now has quite a few callbacks, and I suspect it may
> gain more.  Would it be simpler to make it more like an "abstract base
> class", and to provide the callbacks by inheriting from it and providing
> implementations for some methods?

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

> Given that, "secret_maker" could be made part of Net::OpenID::Server
> since it's something all implementations might need, and it could call
> out to methods which get the server secret.  After all, people can
> override it if they want to use something different.

Heh, I did that last night too.  I even made it generate secrets too,
provided you gave it a storage interface.  But then I couldn't solve the
race condition problems inherent in a caller only providing "get" and
"set" for a time.  So still debating that interface.

- Brad