Marina Vatkina wrote:
> Ron,
>
> Do you see a problem if we make this change permanent?
>
Marina,
if this change relies on a deprecated option, then I think it should be
*temporary*; meaning we should evolve the tests such that they no longer
rely on a deprecated command line password option.
It would probably be better to use the passwordfile if that is feasible,
Ron
ps: is there another run of these dev tests that occurs with a non-empty
admin password? I think we need to be testing that case at least as much
as the no-passowrd mode.
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>