Integrating perl authentication and readers.conf

Erik Klavon erik at eriq.org
Sat Jan 5 23:45:04 UTC 2002


On Fri, Jan 04, 2002 at 06:00:40PM -0500, Jeffrey M. Vinocur wrote:
> 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.

Here is a new syntax I've implemented:

perl_auth: "/path/to/script/auth1.pl"

It is a special type of auth: the only difference is that it calls the
script given as argument using the perl hook rather then an external
program. Multiple/mixed use of auth: and perl_auth: is permitted
within any auth group. Each method is tried in order as they appear in
the auth group.

> What functionality exactly is it you're worried about?

[The following interpretation may not be correct]

The perl connect functionality seems to duplicate what access groups
provide, as well as some of the auth group functionality (less 
authentication via user/pass which perl authenticate provides). The
nntp return value gives perl connect the functionality of the res:
parameter as well as some authentication ability which is provided by
the hosts: parameter and the ability to require authentication.

I don't see a good way to integrate all of this as it stands, other
then to divide everything up and stitch it in, throwing away
redundancies in the perl code. This method kills backwards
compatibility with existing perl scripts (I don't know how much of a
concern this is). 

> 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

Do you mean that one can use either auth: and resolv: or perl: but not
both in an auth group?

> 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 sounds good.

Erik

-- 
erik         | "It is idle to think that, by means of words, | Maurice
  kl at von     | any real communication can ever pass | Maeterlinck
    eriq.org | from one [human] to another." | Silence


More information about the inn-workers mailing list