Bill Shannon wrote:
> 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?
Bill it in RestAdapter -
../v3/admin/rest/src/main/java/org/glassfish/admin/rest/RestAdapter.java
Thanks
Rajeshwar
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
>