Hello, Mike.

Mike said:
> 1) The plugins expect a long-lasting connection, and don't have any
> provision to reconnect if the server goes down. I know our LDAP server
> goes down occasionally, and I wonder if I'd have to restart the
> application in that case. My code makes a separate connection for
> every login, which is the other extreme. The ideal would be for the
> constructor to accept a callable that creates a connection, then reuse
> the existing connection if possible, or if certain exceptions occur,
> create a new connnection. But it looks like I'd have to rewrite the
> plugin for that.

I'm afraid so :/

> 2) The password is put into "repoze.who.identify" after a successful
> login. That seems insecure. The rest of the application doesn't need
> to know what the password is. I could make a metadata provider to
> delete it, but that seems like a kludge.

That's in repoze.who itself, but I don't think that's a problem: It will be 
available in the POST arguments anyway.

> 3) The full DSN is appearing instead of the username in
> "repoze.who.credentials", "repoze.who.identity['repoze.who.userid'],
> and "REMOTE_USER".  I suppose that's correct from LDAP's perspective
> because a username could be ambiguous, but from my perspective the DSN
> is just an internal detail of LDAP, and what I need is the username to
> do authorization with or display.

I agree it makes sense. Possibly the best solution would be to make that 
plugin optionally return the user Id. instead of the whole DN.

> 4) The attributes plugin is not returning the 'ou' and 'ou1'
> properties which I need for authorization.  It's returning only a
> small subset of the LDAP properties. It seems to be returning the ones
> accessible to anonymous users. My code does that if I don't do
> .simple_bind_s as the user.  But the plugin is doing the binding, so I
> don't know why the properties aren't showing up.

Have you tried the `attributes' arguments?

> 5) The plugin doesn't differentiate between "server down", "no such
> user", and "bad password", it just returns None for all of them. This
> makes it impossible to give the user a specific error message.  I
> could make a plugin that puts the info "repoze.who.identity", although
> I think that's supposed to be blank if the login is unsuccessful. But
> I don't want to tell the user they don't exist when the real problem
> is the authentication server being down, or people will think their
> account disappeared.

Good point. That plugin could use a (boolean) environment variable (e.g., 
"repoze.who.ldap.connection_error") which would be checked when the user could 
not be logged in.

> 6) Is it possible for a plugin to combine authentication and metadata
> in one step? Because if it's in a database, I can get both with a
> single query, or if it's in LDAP I can do one right after the other in
> the same connection.

No, because they are two separate processes in repoze.who:

But in practice, that's perfectly possible if you put these attributes in 

> 7) It seems to be rechecking the metadata on every visit after they
> log in, though that could be because my test app is unsophisticated
> and is not saving the metadata in the session. Although if I did do
> that, I'm not sure how to tell Repoze.who that I already have the
> identity and don't need it to refetch the metadata.

You could extend that plugin and override the add_metadata() method, so when 
you already have the data in the session, you put it in the `identity' 
variable passed as argument; if not, you would run the parent class' 


PS: Please note this plugin is in bug-fix mode, not under active development, 
for the time being:
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |
Repoze-dev mailing list

Reply via email to