[tpop3d-discuss] ldap virtual auth plugin : near release

Thu, 21 Feb 2002 14:54:26 +0100

--------------050705030205050401060007
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

>
>
>
>
>>would you please give us an example ?
>>
>
>As a general LDAP example, you could for define an arbitraty group
>by a filter, e.g. all senior developers who have a particular boss, or
>all the color printers on the second floor, assuming you have that data
>in the directory.
>
re,

storing filters in ldap can, maybe, be useful. As storing ACL (really 
useful !)
but, we're talking about 'authenticating users' for a pop service.
This seems to be as structure independant as possible.
The search filter depends on both the popper (the data supplied by the 
user popping his mail) and the tree structure. In fact, whatever the 
tree structure is, the search filter will always be the same :
(&(mail=xxxxx)(objectclass=mailaccount))
which means : search the dn of the user which mail is 'xxxxx' and who 
have a mail account

in this case, I don't see the need of storing this in Ldap.
Then... we could think to add a new module, overtaking utils.c, who will 
get all configuration attrs from Ldap...
It's a conveniant way to have all your configuration parameters at the 
same place. But it's far beyond our need :))))

Prune

--------------050705030205050401060007
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
<blockquote type="cite" cite="mid:20020221134313.GE32761@tantrix.realprogrammers.com">
  <pre wrap=""><br><br></pre>
  <blockquote type="cite">
    <pre wrap="">would you please give us an example ?<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>As a general LDAP example, you could for define an arbitraty group<br>by a filter, e.g. all senior developers who have a particular boss, or<br>all the color printers on the second floor, assuming you have that data<br>in the directory.<br></pre>
    </blockquote>
re,<br>
    <br>
storing filters in ldap can, maybe, be useful. As storing ACL (really useful
!)<br>
but, we're talking about 'authenticating users' for a pop service.<br>
This seems to be as structure independant as possible.<br>
The search filter depends on both the popper (the data supplied by the user
popping his mail) and the tree structure. In fact, whatever the tree structure
is, the search filter will always be the same : <br>
(&amp;(mail=xxxxx)(objectclass=mailaccount))<br>
which means : search the dn of the user which mail is 'xxxxx' and who have
a mail account<br>
    <br>
in this case, I don't see the need of storing this in Ldap.<br>
Then... we could think to add a new module, overtaking utils.c, who will
get all configuration attrs from Ldap...<br>
It's a conveniant way to have all your configuration parameters at the same
place. But it's far beyond our need :))))<br>
    <br>
Prune<br>
    </body>
    </html>

--------------050705030205050401060007--