Hudson web devtest has already run with empty admin.password.
It includes some basic web security tests. It is working fine.
Regards,
Shing Wai Chan
Marina Vatkina wrote:
> I think I found a better solution - v2/appserv-tests/config.properties
> contains the old password, so this change seems to work:
>
>
> Index: config.properties
> ===================================================================
> --- config.properties (revision 27866)
> +++ config.properties (working copy)
> @@ -7,7 +7,7 @@
> https.port=8181
> http.host=localhost
> orb.port=3700
> -admin.password=adminadmin
> +admin.password=
> ssl.password=changeit
> master.password=changeit
> admin.password.file=${env.APS_HOME}/config/adminpassword.txt
>
> Ron, will it work for the security tests?
>
> Regards,
> -marina
>
>
> Tim Quinn wrote:
>> 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>