Integrating perl authentication and readers.conf
Jeffrey M. Vinocur
jeff at litech.org
Fri Jan 4 23:00:40 UTC 2002
On Thu, 3 Jan 2002, Erik Klavon wrote:
[ Be warned that I've never really looked at perlhooks, so I
may say something dumb. ]
> Should a different parameter, such as auth-perl: be used to make clear
> the use of the internal perl hook?
I do not like at all the idea that there is some special string that
causes something that looks like it should invoke a ~news/bin/auth program
to instead magically behave differently. So, then, I suppose yes.
> I am not quite sure how to integrate the perlConnect()
> functionality.
What functionality exactly is it you're worried about?
I've been vaguely thinking about this since I added the ratelimiting stuff
to readers.conf so as not to require perlhooks for that. I have a
potentially crazy but potentially very powerful idea:
- where readers.conf specifies auth: or resolv:, it behaves exactly
as now (specifying a uusername to match against the access blocks)
- where readers.conf specifies perl:, the Perl function called is
expected to (or at least, has the option to) dynamically
generate an access block by populating a hash
That is, instead of being restricted to returning a five-element list, the
perl could set
%access = {
read => "*"
post => "local.*"
virtualhost => "true"
...
}
and thus the perlhook mechanism would provide a strict superset of
readers.conf functionality (even when additional features are added to
readers.conf in the future).
[ Of course, it would be silly to include parameters like users: and key:
here, since no matching would be done. ]
> This, along with the above modifications, should allow the
> use of existing perl auth scripts without modification (a simple
> readers.conf will be needed).
(To get this with the above scheme, you would just add a little Perl
wrapper function to the existing script that pulled out the contents of
the five-element array and stored them in the hash with the appropriate
names.)
> It seems to me that readers.conf and perlConnect overlap in their
> functionality, [...]
Yeah. We need to think this through pretty well to get it right.
> Has anyone else worked on modifications similar to this (I wasn't able
> to find anything when I looked through the list archives)?
Probably not...readers.conf is quite new, after all.
--
Jeffrey M. Vinocur
jeff at litech.org
More information about the inn-workers
mailing list