Ron,
Do you see a problem if we make this change permanent?
thanks,
-marina
Shing Wai Chan wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>