Re: Persisting data across authenticate <-> authorize ?

[prev] [thread] [next] [Date index for 2004/12/14]

On Mon, 2004-12-13 at 22:48 -0700, Tim Pushor wrote:
> >
> My module is an authentication/authorization handler. It worked by 
> issuing an access token that gets stored in one of an array of berkeley 
> DB's. The browser then either sends the token back to the server in the 
> form of a cookie or part of the query string. The token had an expiry on 
> it, and every time the token was used, the TTL was updated.
> 
> So the first crack of the module there was significant lock contention - 
> as every access to every part of the site required an exclusive lock. 
> Then I put in the capability to 'not update token until x time has 
> passed', so rather than updating the token at every access, it would 
> only do it after a certain amount of time had passed.
> 
> This worked very well for me - I still found that to be kind of messy as 
> I thought there should be a better way of keeping track of tokens other 
> than disk access. When I was revamping the C module, I had considered 
> writing a threaded daemon that would keep track of the tokens in memory, 
> with a unix domain socket interface to the httpd processes. This has 
> lots of advantages but is complex.

What we do around here to avoid constant writing to the disk on such
things (we also update the TTL of the token)... we set the expiry time
in the token itself (which in our case is a cookie). The token/cookie of
course is encrypted, so that the user cannot fiddle with it. 

Seems to work a treat, with no write-to-disk required on the server
side... 





> 
> >I don't know how BerkeleyDB implements it, but it's in the C code, not
> >in the Perl code.
> >
> >  
> >
> Yeah, I meant how the IPC::Shareable implements locking (well, 
> IPC::SysV) - I realize this is done in C.
> 
> >The real problem with shared memory things like IPC::Shareable is that
> >they have to serialize and de-serialize your entire data structure using
> >Storable every time you read or write it.  They have no way to address
> >individual entries.  The fast modules handle entries individually.
> >
> >  
> >
> I was planning on doing my own more efficent transformation to/from a 
> scalar, and telling IPC::Shareable to not bother serializing it (I 
> thought I read that this module could do that, but perhaps I was 
> mistaken (maybe I was incorrectly thinking of Cache::FastMmap).
> 
> Thanks,
> Tim
> 
> 
--
If the laws do not server the men,
change the laws, not the men.



        -- 
        Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html