LDAPUserManager

[Niklas Gustavsson <ni...@protocol7.com>]

Is anyone currently using the LDAPUserManager? I'm looking into doing a 
complete rewrite if it that would do a regular LDAP bind to authenticate 
the user and then look up LDAP attributes. This would different from 
today when a full Java User object is stored in the LDAP directory. Do 
this rewrite would enable us to work with any LDAP directory, e.g. 
Active Directory.

Using bind is the same method as used by Acegi Security. I'm also 
considering providing an adapter to Acegi and completely remove our LDAP 
UM, instead pointing at the Acegi one.

/niklas

Re: How to identify sessions

[Mark Proctor <li...@markproctor.com>]

doh! you've already made it do key/value pairs, should have read the 
email more closely. Just trying it out now.

Mark
Mark Proctor wrote:
> Yup that's fine, I can store a HashMap in there with key/value pairs 
> for that session. We need  to get an FAQ together for this sort of 
> stuff  :)
>
> Mark
> Niklas Gustavsson wrote:
>> Mark Proctor wrote:
>>> I would  like to store additional session data for a sesssion. I was 
>>> going to do this by having a HashMap in the FtpLet, but I need to 
>>> find a unique key for the request. Currently I can only think of 
>>> using connection time and user name, but this cannot be guaranteed 
>>> to be unique. Could we maybe have a long counter that is incremented 
>>> for each connection which can be used as an id and always available 
>>> from the FtpRequest?
>>
>>
>> On FtpRequest you will find get/setAttribute() methods which are 
>> meant for storing session associated data. Would this suffice for you?
>>
>> With the MINA refactoring coming up I'm planing for a more dedicated 
>> session interface (split out from RequestHandler and FtpRequest).
>>
>> /niklas
>>
>>
>
>

Re: How to identify sessions

[Mark Proctor <li...@markproctor.com>]

Yup that's fine, I can store a HashMap in there with key/value pairs for 
that session. We need  to get an FAQ together for this sort of stuff  :)

Mark
Niklas Gustavsson wrote:
> Mark Proctor wrote:
>> I would  like to store additional session data for a sesssion. I was 
>> going to do this by having a HashMap in the FtpLet, but I need to 
>> find a unique key for the request. Currently I can only think of 
>> using connection time and user name, but this cannot be guaranteed to 
>> be unique. Could we maybe have a long counter that is incremented for 
>> each connection which can be used as an id and always available from 
>> the FtpRequest?
>
>
> On FtpRequest you will find get/setAttribute() methods which are meant 
> for storing session associated data. Would this suffice for you?
>
> With the MINA refactoring coming up I'm planing for a more dedicated 
> session interface (split out from RequestHandler and FtpRequest).
>
> /niklas
>
>

Re: How to identify sessions

[Niklas Gustavsson <ni...@protocol7.com>]

Mark Proctor wrote:
> I would  like to store additional session data for a sesssion. I was 
> going to do this by having a HashMap in the FtpLet, but I need to find a 
> unique key for the request. Currently I can only think of using 
> connection time and user name, but this cannot be guaranteed to be 
> unique. Could we maybe have a long counter that is incremented for each 
> connection which can be used as an id and always available from the 
> FtpRequest?


On FtpRequest you will find get/setAttribute() methods which are meant 
for storing session associated data. Would this suffice for you?

With the MINA refactoring coming up I'm planing for a more dedicated 
session interface (split out from RequestHandler and FtpRequest).

/niklas

How to identify sessions

[Mark Proctor <li...@markproctor.com>]

I would  like to store additional session data for a sesssion. I was 
going to do this by having a HashMap in the FtpLet, but I need to find a 
unique key for the request. Currently I can only think of using 
connection time and user name, but this cannot be guaranteed to be 
unique. Could we maybe have a long counter that is incremented for each 
connection which can be used as an id and always available from the 
FtpRequest?

Mark

Re: Pass, onLogin and User

[Niklas Gustavsson <ni...@protocol7.com>]

Mark Proctor wrote:
> What we have at the moment isn't intuitive. I would probably load the 
> User class as default and add a field authorized true/false. Also don't 
> forget to remove the intial "User user = request.getUser() " as its 
> currently redundant.
> 
> Mark
> 
> Any catching of exceptions from user defined FtpLets should be logged, 
> debug makes sense.

Hopefully both of these should now been taken care of. Feel free to 
harass me further if your not happy with how I solved them :-)

/niklas

Re: Pass, onLogin and User

[Mark Proctor <li...@markproctor.com>]

What we have at the moment isn't intuitive. I would probably load the 
User class as default and add a field authorized true/false. Also don't 
forget to remove the intial "User user = request.getUser() " as its 
currently redundant.

Mark

Any catching of exceptions from user defined FtpLets should be logged, 
debug makes sense.

Niklas Gustavsson wrote:
> Mark Proctor wrote:
>> The onLogin request.getUser() returns null. So I started looking at 
>> the PASS class:
>> String userName = request.getUserArgument()
>> User user = request.getUser()
>> So here you are requesting user, which is always null, but even if it 
>> did return a value you never use it anyway as user is later nulled as 
>> it's actually set by the authentication code. Further to this you 
>> call the onLogin method before you do the  request.setUser(user), so 
>> I guess I'm asking should User be available from onLogin or not? 
>
> As it works right now, the Ftplet is given the possibility of denying 
> the login. Maybe we should change this so that we first set the status 
> as it would be logged in, and then if the Ftplet returns RET_SKIP we 
> reset the status so that the user is now set as denied access. I would 
> be happy to make this change if you think it makes sense.
>
>> If not, this should probably be documented. Either way the fist user 
>> assigment and null check is redundant. I also notied that you are 
>> swollowing Exceptions thrown by the FtpLets, even null pointers, 
>> these should be atleast logged, as it makes tracking down bugs that 
>> are occuring in them difficult.
>
> By this you mean for example:
> try{
>     ftpletRet = ftpletContainer.onLogin(request, out);
> } catch(Exception e) {
>     ftpletRet = FtpletEnum.RET_DISCONNECT;
> }
>
> Adding a log there would make sense, possibly at DEBUG level?
>
> /niklas
>
>

Re: Pass, onLogin and User

[Niklas Gustavsson <ni...@protocol7.com>]

Mark Proctor wrote:
> The onLogin request.getUser() returns null. So I started looking at the 
> PASS class:
> String userName = request.getUserArgument()
> User user = request.getUser()
> So here you are requesting user, which is always null, but even if it 
> did return a value you never use it anyway as user is later nulled as 
> it's actually set by the authentication code. Further to this you call 
> the onLogin method before you do the  request.setUser(user), so I guess 
> I'm asking should User be available from onLogin or not? 

As it works right now, the Ftplet is given the possibility of denying 
the login. Maybe we should change this so that we first set the status 
as it would be logged in, and then if the Ftplet returns RET_SKIP we 
reset the status so that the user is now set as denied access. I would 
be happy to make this change if you think it makes sense.

> If not, this 
> should probably be documented. Either way the fist user assigment and 
> null check is redundant. I also notied that you are swollowing 
> Exceptions thrown by the FtpLets, even null pointers, these should be 
> atleast logged, as it makes tracking down bugs that are occuring in them 
> difficult.

By this you mean for example:
try{
     ftpletRet = ftpletContainer.onLogin(request, out);
} catch(Exception e) {
     ftpletRet = FtpletEnum.RET_DISCONNECT;
}

Adding a log there would make sense, possibly at DEBUG level?

/niklas

Pass, onLogin and User

[Mark Proctor <li...@markproctor.com>]

The onLogin request.getUser() returns null. So I started looking at the 
PASS class:
String userName = request.getUserArgument()
User user = request.getUser()
So here you are requesting user, which is always null, but even if it 
did return a value you never use it anyway as user is later nulled as 
it's actually set by the authentication code. Further to this you call 
the onLogin method before you do the  request.setUser(user), so I guess 
I'm asking should User be available from onLogin or not? If not, this 
should probably be documented. Either way the fist user assigment and 
null check is redundant. I also notied that you are swollowing 
Exceptions thrown by the FtpLets, even null pointers, these should be 
atleast logged, as it makes tracking down bugs that are occuring in them 
difficult.

Mark