Integrating perl authentication and readers.conf

[Jeffrey M. Vinocur]

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