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).