Net::OpenID::Server

Troy Benjegerdes hozer at hozed.org
Tue May 24 11:00:39 PDT 2005


> >>I have been halted by the quandry of how to handle the auth step. My 
> >>first thought was to keep it simple and use HTTP auth, but digest auth 
> >>in a CGI script isn't easy because of the need to retain the pending 
> >>nonces. In general, maintaining any kind of state across requests is a 
> >>royal pain in a CGI script.
> >
> >
> >Can you use apache HTTP Auth and look at the $REMOTE_USER variable?
> 
> I covered that in the following paragraph which you snipped! The 
> Consumer eventually needs to request the public key at the same URL, so 
> Apache would need some way to distinguish between the auth request and 
> the key request.

I guess the apache auth stuff was a little more limited than I though it
was at first. But I'm wondering if a .htaccess file like the following 
would work...

AuthUserFile .htmlpasswd
AuthGroupFile /dev/null
AuthName source
AuthType Basic
# Users authenticate..
require valid-user
Order allow,deny
# list of allowed consumer sites
allow from livejournal.com danga.com example.com
satisfy any


> >What about a CGI script and daemon that runs to keep the nonce data? For
> >anything less than 100 or so users, would flat files work out?
> 
> Having to run a daemon increases the barrier of entry. Most people don't 
> have the ability to do that. The goal here was to give people something 
> that they can just install on their crummy web hosting account and use.

Are you allowed to fork from a CGI? The cgi can check if there's a
daemon listening on a unix named pipe/socket/whatever, and fork off a daemon
if there is nothing there.

> My original concern about maintaining state was the need for file 
> locking, but now that I think about it an ID server only supporting one 
> user should in theory never get two simultaneous requests. Probably best 
> not to rely on that, though, or else it could be valnerable to a denial 
> of service attack.
> 
> In general, I think a simple ID server of this nature would be better 
> implemented in PHP, for the reasons I stated in my original message. I 
> don't know how to do SHA1 and DSA in PHP, though.

If the goal is a simple auth server that can go on any old crummy
webhost site, PHP might be better. But there are a lot of people that
have linux/unix/whatever machines on DSL or accounts with a shell that
would be quite happy with a simple perl CGI.




More information about the yadis mailing list