Rana,

First, I want to move all security checks to security manager. As you can
see, I add deprecated tag to FileObject methods, to move them to
SecurityManager. So it is only temporary duplication of functions to
simplify changing code.

Second, from my point of view, FileObject should be able to not depends on
UserObject. Only FileSystemView should contains reference to UserObject.
Does or does not FileObject contain reference to User - is the question of
implementation. IMO, implementation would be much simple, if FileObject
doesn't depends on UserObject.

And third, the main point. Security system should be more flexible, than
just 3 methods canRead, canWrite, canDelete.

Sergey

2006/5/17, Rana Bhattacharyya <[EMAIL PROTECTED]>:

Hi,

   Why do you need this. FileObject already has
canRead(), canWrite(), canDelete() methods.

FileObject depends on UserObject because the
FileSystemView depends on UserObject.

FileSystemSecurityManager looks like an add-hoc
solution for something which already exists.

Thanks,
Rana Bhattacharyya


--- Sergey Vladimirov <[EMAIL PROTECTED]> wrote:

> Hi, ftpserver-dev,
>
> By this patch I want to introduce
> FileSystemSecurityManager component. It
> should check all file permissions, and it should be
> the single place to
> check all rights.
> The reason to introduce so many methods (instead of
> original hasRead,
> hasWrite, hasDelete) is some application that
> requires different rights to,
> for example, creating files and creating
> directories.
>
> --
> Sergey Vladimirov

--
Sergey Vladimirov

Reply via email to