I think you want the password file to contain
AS_ADMIN_PASSWORD=
on a line by itself - no quote marks.
- Tim
Kin-man Chung wrote:
> I think the argument is not with the change of authentication, which
> I agree is more secure, but with the default configuration for the
> default domain. It used to be that "admin" requires a password
> (adminadmin), but now it doesn't, which breaks existing tests. I
> think users will complain about this too.
>
> I can make a test to run if I remove "--user admin --passwordfile <f>",
> like Shing Wai suggested, or make <f> an empty file. Strangely, if
> <f> contains a single line
> AS_ADMIN_PASSWORD=""
> it still fails.
>
> On 09/14/09 21:20, Bill Shannon wrote:
>> Sorry guys, I'm just getting back to the thread.
>>
>> While this change is working as intended, the thing that surprises me
>> is how many places have *incorrect* authentication information for the
>> domain. If you pass in *no* authentication information (which is what
>> I was expecting people were doing for anonymous login), then it pretty
>> much works as before. But if you pass in *incorrect* authentication
>> information (wrong username or wrong password), it now fails. This is
>> to avoid the case where you login to a domain using what you know are
>> the correct username and password, and the login succeeds, but in fact
>> a configuration error in the domain set it up for
>> anonymous/unauthenticated
>> access. Before this change you would have a false sense of security and
>> the configuration error would go undetected. After the change the error
>> is detected.
>>
>> If you have a password file with an incorrect password for the domain,
>> you need to fix that, most likely by simply removing the password from
>> the password file.
>>
>> If you've logged into the domain using "asadmin login", or created a
>> domain using the --savelogin option, you might have a saved password
>> that's now incorrect. You can either remove the ~/.asadminpass file
>> or use "asadmin login" to specify the correct password.
>>
>> Hopefully the problems caused by this change are just transitory until
>> all the configuration errors are corrected. If it proves to be more of
>> a problem than that, we can consider restoring the previous behavior, at
>> the cost of reintroducing the "false sense of security" problem.
>>
>>
>> Kedar Mhaswade wrote on 9/14/09 6:35 PM:
>>> Kin-man Chung wrote:
>>>> In the interest of backward compatibility, asadmin should just ignore
>>>> the --passwordfile options if the domain was created with no password.
>>>> Otherwise a lot of scripts and ant tasks will no longer work. This is
>>>> a serious problem for devtests, which need to run in various versions
>>>> of the appserver.
>>> Probably you are right and we might have to do something if this
>>> remains confusing but I don't think there is any v2-compatibility issue
>>> here. After talking to Bill, I agree with him that the change he's made
>>> is correct and makes the domain more secure. (A long-winding
>>> explanation
>>> ...)
>>>
>>> The only "change" is that in v2, the setup.xml
>>> used to create the domain with "admin"/"adminadmin" and in v3 the
>>> .zip bundles create a preconfigured domain with "admin"/no-password.
>>>
>>> v3-final is going to be incompatible with earlier releases of v3
>>> (Prelude/Preview) because v3 (Prelude/Preview) ignored all
>>> user names/passwords with default domain (that is bundled in
>>> the web.zip/glassfish.zip bundles). I am not sure if we must
>>> preserve v3-final's compatibility with Preview/Prelude.
>>>
>>> One idea is to make the password for "admin" user "adminadmin"
>>> instead of no-password, which will fix most of the tests, but
>>> this idea is is rather weird too (conflicts with --no-password
>>> option on create-domain).
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>