[FtpServer] User interface design

[Niklas Gustavsson]

> From Andrea Francia
>
> Moreover I don't clearly see the difference between attempting authorizing a user and know if a user is authorized to do something.
> Could you explain me, please?

One use case would be where you have an administration tool for
FtpServer and would like to list users and there authorities.

> Moreover I'm not convinced about the usage of AuthorizationRequest as a result type.
> I see that the authorization request is used as a result to bring some values to the caller, like the case of the TransferRateRequest that returns back the maxDownloadRate, and the maxDownloadRate.
> Why not a AuthorizationResult?

This is modelled slightly after Spring Security. Request might not be
a good name the interface, but the general idea is to sent a request
and have the relevant authority fill in the details. As this is
chained , we could not do a simple request/response pair.

/niklas

[Andrea Francia-3]

Niklas Gustavsson wrote:
>> From Andrea Francia
>>
>> Moreover I don't clearly see the difference between attempting authorizing a user and know if a user is authorized to do something.
>> Could you explain me, please?
>>    
>
> One use case would be where you have an administration tool for
> FtpServer and would like to list users and there authorities.
>  
I think that the methods of the User interface should be divided in two
categories:
 1. method that are called from ftpserver-core
 2. method that are called from something administration tool

While the methods of type 1 are mandatory to get a working FTP server
the methods of type 2 are not.

For example I'm writing an FTPServerStub to be used in unit testing, I
wont write an Authority[] getAuthorities() method. None call thesse
methods, I never seen an Administration Tool for the Apache FTP Server
and my classes are not designed to be administered (they are only for
unit test purpouse).
Now, I known, after searching in the code of ftpserver-core that I could
simply return nulls.
But a end user of the FTPlet library should read these informations from
the docs.

The same will apply to the UserManager interface. I think that the
UserManager#save() should be optional. Some UserManager could be read-only.

We can use the same solution used by the Java Collection Framework: some
methods can be optionally implemented.
For example some methods of the List interface are optional:

From:
http://java.sun.com/docs/books/tutorial/collections/interfaces/list.html

> public interface List<E> extends Collection<E> {
>     // Positional access
>     E get(int index);
>     E set(int index, E element);    //optional
>     boolean add(E element);         //optional
>     void add(int index, E element); //optional
>     E remove(int index);            //optional
>     boolean addAll(int index,
>         Collection<? extends E> c); //optional
>
>     // Search
>     int indexOf(Object o);
>     int lastIndexOf(Object o);
>
>     // Iteration
>     ListIterator<E> listIterator();
>     ListIterator<E> listIterator(int index);
>
>     // Range-view
>     List<E> subList(int from, int to);
> }

All optional methods have a javadoc like this:

    /**
     ....
     * @throws UnsupportedOperationException if the <tt>remove</tt>
operation
     *         is not supported by this list
     */
    boolean remove(Object o);

>> Moreover I'm not convinced about the usage of AuthorizationRequest as a result type.
>> I see that the authorization request is used as a result to bring some values to the caller, like the case of the TransferRateRequest that returns back the maxDownloadRate, and the maxDownloadRate.
>> Why not a AuthorizationResult?
>>    
>
> This is modelled slightly after Spring Security. Request might not be
> a good name the interface, but the general idea is to sent a request
> and have the relevant authority fill in the details. As this is
> chained , we could not do a simple request/response pair.
>  

I don't know how the Spring Security wotks.
I don't understand what means that the result is chained.

Could someone explain it to me?

--
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html

[Niklas Gustavsson]

On Wed, Oct 1, 2008 at 8:29 PM, Andrea Francia <andrea@...> wrote:
>> One use case would be where you have an administration tool for
>> FtpServer and would like to list users and there authorities.
>
> I think that the methods of the User interface should be divided in two
> categories:
> 1. method that are called from ftpserver-core
> 2. method that are called from something administration tool

If by "administrative tool" you mean any code that uses the FtpServer
API, then I agree. The admin tool, as I mentioned, is only one of many
potential use cases. FtpServer is designed for embedding and we don't
know what embedders would like to do, we can only make some
assumptions.

> While the methods of type 1 are mandatory to get a working FTP server the
> methods of type 2 are not.
>
> For example I'm writing an FTPServerStub to be used in unit testing, I wont
> write an Authority[] getAuthorities() method. None call thesse methods, I
> never seen an Administration Tool for the Apache FTP Server and my classes
> are not designed to be administered (they are only for unit test purpouse).
> Now, I known, after searching in the code of ftpserver-core that I could
> simply return nulls.


As with all implementations of interfaces, the implementor to choose
to do whatever fits his/her case. In your example of using mocks, not
implementing getAuthorities might make perfect sense.

> But a end user of the FTPlet library should read these informations from the
> docs.

Agreed.

> The same will apply to the UserManager interface. I think that the
> UserManager#save() should be optional. Some UserManager could be read-only.

Yes, this is already the case. Maybe we should do what is discussed
for JSecurity where there is currently only an immutable "user
manager" while there has been some discussions on being able to extend
it to be mutable.

>> This is modelled slightly after Spring Security. Request might not be
>> a good name the interface, but the general idea is to sent a request
>> and have the relevant authority fill in the details. As this is
>> chained , we could not do a simple request/response pair.
>
> I don't know how the Spring Security wotks.

Here's the matching class from Spring Security:
http://static.springframework.org/spring-security/site/apidocs/org/springframework/security/Authentication.html

> I don't understand what means that the result is chained.

It means that the request is sent to several authorities which can all
change the permissions given to the user.

/niklas