Implementing FTPServer User Manager in OSGi

[Dave Roberts <da...@saaconsultants.com>]

It's possible to deploy FTP Server post 1.0.8 in an OSGi container.
However creating a different User Manager implementation is not
without problems.

Consider that the USER class checks to see if the user logging in is
permitted to do so concurrently.  This is done by creating an
instance of
org.apache.ftpserver.usermanager.impl.ConcurrentLoginRequest and
passing that to the authorize(AuthorizationRequest) method for the
User object.

If that User implementation is not one that's included with FTP
Server, then the new implementation has no way of handling the
request in a reasonable manner because the package
org.apache.ftpserver.usermanager.impl is not exported in the OSGi
container.

Is it intended that such functionality is "private", or should there
be suitable interfaces created for the *Request classes, and
potentially move the Authority implementations also, so that they
may be re-used?  In which case it'd be nice to expose the BaseUser
class as well.

I'm happy to make some changes and submit patches, but don't want to
go off in a different direction than that intended by the team.

Re: Implementing FTPServer User Manager in OSGi

[Dave Roberts <da...@saaconsultants.com>]

On 31/07/2013 22:07, Niklas Gustavsson wrote:

>> It's possible to deploy FTP Server post 1.0.8 in an OSGi
>> container.

Sorry, I meant post 1.0.6.  There is no 1.0.8 (yet).

> Anyhow, the idea is that the UserManager/User shouldn't need to
> care about Authority/AuthorizationRequest implementations.

I'd agree with that, but as the USER class creates a specific
AuthorizationRequest to pass into the User, then clearly the User
implementation needs to be able to do something with it.

We could move the methods getConcurrentLogins() and
getConcurrentLoginsFromThisIP() to the User interface, and call
those methods directly from USER.execute().  It can be argued that
the precedent for having properties on the User has been set by the
maxIdleTime.  However it obviously doesn't scale well, and changes
the API.

A more subtle change would be to create something like:-

public interface ConcurrentLoginAuthorizationRequest extends
AuthorizationRequest

.. within the ftplet-api.  The existing ConcurrentLoginRequest can
then implement this new interface instead.

This would be a non-breaking change and allow User implementations
to handle the authorise request.

Then the same could be done for the other AuthorizationRequest
classes, though I've not looked into where they are used yet.
Having a bit of problem getting set up with GIT and importing the
project/modules into Eclipse properly.

Re: Implementing FTPServer User Manager in OSGi

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

On Wed, Jul 31, 2013 at 4:47 PM, Dave Roberts
<da...@saaconsultants.com> wrote:
> It's possible to deploy FTP Server post 1.0.8 in an OSGi container.
> However creating a different User Manager implementation is not
> without problems.
>
> Consider that the USER class checks to see if the user logging in is
> permitted to do so concurrently.  This is done by creating an
> instance of
> org.apache.ftpserver.usermanager.impl.ConcurrentLoginRequest and
> passing that to the authorize(AuthorizationRequest) method for the
> User object.
>
> If that User implementation is not one that's included with FTP
> Server, then the new implementation has no way of handling the
> request in a reasonable manner because the package
> org.apache.ftpserver.usermanager.impl is not exported in the OSGi
> container.
>
> Is it intended that such functionality is "private", or should there
> be suitable interfaces created for the *Request classes, and
> potentially move the Authority implementations also, so that they
> may be re-used?  In which case it'd be nice to expose the BaseUser
> class as well.
>
> I'm happy to make some changes and submit patches, but don't want to
> go off in a different direction than that intended by the team.

I'll say right out that the OSGi stuff isn't perfect in any way.

Anyhow, the idea is that the UserManager/User shouldn't need to care
about Authority/AuthorizationRequest implementations. That said,
setting up a user with the correct authorities in the user manager,
like in PropertiesUserManager.getUserByName() won't work with OSGi.

Patches would be most welcome!

/niklas