Hi, Sorry, I beg to differ.
1. In my opinion, the API should be as simple as possible. Also it should be easy to understand. In this case, we are getting FileSystemView by passing User and we are getting FileObject from FileSystemView. So the FileObject depends on User anyway. How you can say that the FileObject cannot depend on User when the underlying API says otherwise. The FileSystemSecurityManager can be a custom API developed by the integrator but should not be used in the server. 2. If you check different java file system APIs, all of them have some commonalities ie. getName(), canRead(), canWrite() etc. Why do we need to change this without gaining anything much. 3. FileSystemSecurityManager will introduce confusion in the API design. If you want to do some custom permission checking to append, you can always do that using ftplet. If we want to solve this by introducting FileSystemSecurityManager, we will end up implementing other security check like do I have the permission to read a file from an specified index or can I delete a file at say midnight. We can easily solve these using ftplet. Then why FileSystemSecurityManager? Thanks, Rana Bhattacharyya --- Sergey Vladimirov <[EMAIL PROTECTED]> wrote: > 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 > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
