dev@glassfish.java.net

Re: different behaviors for admin user without password

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Wed, 16 Sep 2009 16:54:05 -0700

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.
If it goes through the GenericAdminAuthenticator it should work
like the CLI.

Possibly your browser has authentication information cached that
it's sending on every request even though the server isn't asking
for it? In that case, if it sends the wrong information then just
like the CLI it's going to fail. If it sends *no* authentication
information that we should be able to make it succeed just like
the CLI.