Hi, 1. SecurityManager and UserManager are two different activities. So there should be two different components where *both of them are required*. UserManager to obtains Users (as factory), SecurityManager - to check permissions.
2. SecurityManager will use User and UserManager will create such User. Credentials will not be used by anyone, except commands USER and PASS. 3. FileSystemView should not depends on User neither on Credentials. In fact, I want to move all security-related checks from FileSystemView to SecurityManager. Commands like MKD, GET, PUT etc should pass Request and FileObject(s) to SecurityManager and ask permission to do operations. 4. Why UserManager is optional? I think it is required. The question is - will all UserManager implementations allow us to create Users? My answer is no. Sergey 2006/5/5, Rana Bhattacharyya <[EMAIL PROTECTED]>:
Hi, These are the things I understand. 1. SecurityManager and UserManager are two different activities. So there should be two different components where UserManager is an optional component. 2. SecurityManager will use Credentials and UserManager will use User. As the UserManager is an optional component, the User is also an optional object. 3. FileSystemView depends on what .... Credentials or User? It is not very clear. 4. We will be able to create User when we have an UserManager (which is an optional component). Please write your comments about my understanding. Let us first clarify our doubts then we shall think about implementations. We do not want to modify the codebase in a hurry when there is a major change. Now I understand what Niklas Gustavsson meant by "Inversion of Control" :). Niklas, where are you? Thanks, Rana Bhattacharyya --- Sergey Vladimirov <[EMAIL PROTECTED]> wrote: > Hi, Rana, > > 1. User Manager can use any User implemetation, this > is true. But what > should, for example, FileSystemManager use if it > need user implementation > from UserManager, not BaseUser? > For current moment it need to take user name from > request and lookup for > actual User from UserManager. > I don't think it is good. I don't think that > isolation User from UserManager > and User in request is good idea. In fact, my own > implementations of > FileSystemManager and SecurityManager would be much > simple with just storing > User from UserManager in Request. > More over, it is much better from perfomance point > of view. > > 2. Creating Users should be optional possibility of > UserManager, not > FTPServer. One more time about mine implementatios - > they don't allow to > create new users at all. > If "setters" needs only to create users, just leave > them in > AbstractUserManager which would use BaseUser. > > 5. Using BaseUser as Credentials is confusing. I > prefer to set user to null > until it is logged-in. > > Sergey > > 2006/5/5, Rana Bhattacharyya <[EMAIL PROTECTED]>: > > > > Hi, > > > > Please find my comments below. > > > > 1. User manager can use any User implementation. > It is > > not necessary to use BaseUser. It just happens > that > > the user managers provided with the server use > > BaseUser. > > > > 2. From API point of view, we only need the > getters > > method from the User interface. But for setting we > > need setters. So BaseUser has both getters and > > setters. We need these setters for creating users. > > > > 3. The FTP server populates BaseUser to isolate > > UserManager provided User implementation and the > > BaseUser used internally. We do not assume that > the > > UserManager provided User is BaseUser. > > > > 4. Probably, we can rename BaseUser to say FtpUser > to > > remove the confusion. > > > > 5. We are using BaseUser internally just like the > > Credentials object. > > > > Thanks, > > Rana Bhattacharyya > > > > > > > > --- Sergey Vladimirov <[EMAIL PROTECTED]> wrote: > > > > > Добрый день, Антон > > > Good day, Anton, > > > > > > I considered different ways of implementation. > At > > > least two of them: > > > 1. Store user name in request until user log-in. > > > 2. Retrieve user by user name from UserManager, > but > > > set the flag, that it is > > > not init yet. > > > > > > I selected first way, because there is > possibility > > > to create UserManager > > > which can retrieve user only with user name and > > > password. So we need to > > > store user name. > > > But I prefer to do it in new class, Credentials, > > > instead of using new String > > > field, because it is more readable and > > > understandable from my point of view. > > > > > > So by this patch I "fix" two issues at one time: > > > 1. Partially replace BaseUser with it > UserManager > > > specific implementation > > > 2. Remove User from Request until User is > logged-in. > > > > > > Sergey > > > > > > 2006/5/5, Anton Goldberg > <[EMAIL PROTECTED]>: > > > > > > > > Hi Sergey, > > > > (or should I say Sdravstvuy!). I looked > through > > > your patch and while I > > > > totally agree with the idea behind the patch I > > > don't quite understand > > > > the implementation. > > > > Let me go into more details here. > > > > As far as I understand UserManager works like > a > > > Factory (pattern) for > > > > User. I.e. the particular implementation of > > > UserManager knows what > > > > specific class implementing User interface it > > > needs to instantiate. So > > > > the default (BaseUser) implementation should > be > > > replaced by > > > > UserManager supplied implementation on log-in. > > > (PASS/USER commands). > > > > As a thing that gets replaced BaseUser works > just > > > fine, without > > > > introducing the new class Credentials, because > > > Credentials exposes a > > > > subset of User (and BaseUser) functionality. > > > > > > > > Now I have a slightly different issue - if you > > > noticed, I didn't reply > > > > to the list. The reason being that while I > > > subscribed to the list > > > > fine, I am unable to post from any of my email > > > addresses - I tryed my > > > > workaddress, this gmail account and also my > > > personal mail server. I > > > > wonder if you in your contributor role could > check > > > it out and let me > > > > know what might be the reason I can not post. > > > > > > > > You are quite welcome to reply in Russian, my > > > email client can read > > > > russian letters just fine. > > > > -- > > > > Anton > > > > > > > > > > > > > > > > -- > > > Sergey Vladimirov > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > > -- > Sergey Vladimirov > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-- Sergey Vladimirov
