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