Rajeshwar Patil wrote on 9/16/09 5:32 PM:
> Bill Shannon wrote:
>> Kedar Mhaswade wrote on 09/16/09 16:09:
>>> Shing Wai Chan wrote:
>>>> Kedar Mhaswade wrote:
>>>>> Shing Wai Chan wrote:
>>>>>> Bill Shannon wrote:
>>>>>>> Shing Wai Chan wrote on 09/16/09 14:20:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I find that Admin GUI and (Admin CLI, REST) behave differently
>>>>>>>> for admin user without password.
>>>>>>>>
>>>>>>>> Scenario 1:
>>>>>>>> There is only one admin user with name "admin" without password.
>>>>>>>> Admin GUI, CLI and REST do not prompt for the password.
>>>>>>>>
>>>>>>>> Scenario 2:
>>>>>>>> There is only one admin user with name "anonymous" without
>>>>>>>> password.
>>>>>>>> Admin GUI does not prompt for the password.
>>>>>>>> CLI and REST "do prompt" for the (empty) password.
>>>>>>>>
>>>>>>>> So, Admin GUI and (Admin CLI, REST) do behave differently.
>>>>>>>> I think they should be consistent.
>>>>>>>
>>>>>>> How are you running the admin CLI? Are you specifying "--user
>>>>>>> anonymous"?
>>>>>>> Do you have AS_ADMIN_USER set in your environment? Do you have
>>>>>>> an entry
>>>>>>> in ~/.asadminpass for the server you're connecting to?
>>>>>> I run the CLI as follows (no --user):
>>>>>> asadmin list-components
>>>>>>
>>>>>> I do not set AS_ADMIN_USER
>>>>>> In my ~/.asadminpass, it has the following:
>>>>>> asadmin://admin_at_localhost:4848
>>>>>
>>>>> Right, this means that asadmin program is sending
>>>>> "admin"/no-password to a server located at localhost:4848,
>>>>> which like you said is configured for "anonymous"/no-password.
>>>>>
>>>>> If you remove that entry or remove/backup .asadminpass, you'll
>>>>> see what you expect (assuming you don't do other things).
>>>> In this case, how should we look at REST and admin GUI?
>>>> Both are going through browser. One prompts for password, but not
>>>> for the other.
>>>
>>> Well, Admin GUI and CLI are our clients, meaning we can write them so
>>> they have in a certain manner. With a browser and HTTP/REST commands,
>>> you don't have that luxury and standard 401/403 HTTP status codes
>>> are sent by the backend that browser interprets in a standard way, in
>>> this case by popping up a login dialog. I don't know how we can
>>> make it better other than providing some JavaScript stuff.
>>
>> I'm not sure how authentication is done for the REST interface.
> REST interface is currently using AdminAuthenticator. REST interface
> behaviour is exactly same as CLI. Shing Wai Chan point is that the
> CLI/REST behaviour is different that Admin UI.
AdminAuthenticator is just an interface, the only implementation of which
I see is FileBasedAdminAuthenticator. Kedar was *sure* that
FileBasedAdminAuthenticator wasn't being used, so I didn't update it to
handle the new rules. If in fact it is being used for REST, I'll need to
update it as well. Where do I look for the REST code that uses
AdminAuthenticator? Perhaps it should be updated to use the
AdminAccessController interface instead of the AdminAuthenticator interface?
I really don't know what the plan is here for these two slightly different
interfaces.
The difference between CLI and admin GUI is that with the GUI you have
absolutely no opportunity to provide authentication information
before the admin GUI displays the login screen (or not). With CLI,
the http request might or might not contain authentication information,
which the server will use if it's present. If it's absent, the behavior
is the same as the admin GUI - you either get logged in automatically or
it tells you that it needs authentication information.