Ron Monzillo wrote:
> 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,
It's used to create the password file and then pass it to the
--passwordfile option.
Regards,
-marina
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>