On 4/19/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
Matt Raible wrote:
> The old code probably did some checking in the edit() method to see if
> the user logged in with Remember Me. If so, it set that value, which
> the JSP checked and hid the fields for.
I looked at that, but all that I can see is a conditional in the edit()
method which adds an action message if it's a cookie login, and in the
jsp it doesn't show the password fields if it's a cookie login. I
couldn't find anywhere in the code where that cookie login state is
actually set, the only thing i can think of is if it happens inside of
the Acegi code.
That's weird - here's what I use in AppFuse in the UserAction.edit() method:
// if user logged in with remember me, display a warning that they
can't change passwords
log.debug("checking for remember me login...");
AuthenticationTrustResolver resolver = new
AuthenticationTrustResolverImpl();
SecurityContext ctx = SecurityContextHolder.getContext();
if (ctx != null) {
Authentication auth = ctx.getAuthentication();
if (resolver.isRememberMe(auth)) {
getSession().setAttribute("cookieLogin", "true");
saveMessage(getText("userProfile.cookieLogin"));
}
}
>
> A better solution for the JSP is to remove the fields completely, then
> use a Preparable interface on UserAction (or whatever its called) to
> refetch the user on save. That way, all the values from the database
> would be retained, and any ones specified in request parameters (from
> the form) would be overwritten.
Well, we do lookup the user when a profile save happens and we only set
the properties which are allowed to be changed. I don't think it's good
usability to remove the password fields though. If someone is logged in
via a remember me cookie then they should be in equal standing with any
other logged in user.
I'm fine with that, but when I first started digging into the Remember
Me stuff (years ago) a lot of folks recommended that it not be given
the same status as a user who logs in with a keyboard.
Matt
-- Allen
>
> Matt
>
> On 4/19/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
>> I just wanted to send this out to make sure I am not wrong about this.
>> In the new struts2 profile update form I have removed a small amount of
>> code which tried to prevent users who were logged in via a 'cookieLogin'
>> from changing their passwords. I don't really know the history behind
>> this code and don't even know if it was working anymore, but I am
>> removing it because ...
>>
>> 1. It *looks* like it doesn't even take effect anymore because I can't
>> find anywhere in the code which sets the "cookieLogin" attribute on a
>> session to trigger the behavior.
>>
>> 2. The old code wasn't actually preventing this scenario, it was only
>> discouraging it. In the old action & jsp it would simply not display
>> the password form fields when the user had logged in via cookie, but
>> technically if you submitted the form with the right fields the action
>> would accept them and modify the password.
>>
>> 3. If this is still a valid security constraint that we want to imply
>> then I think we can do it in a better way, i.e. to ask for the users
>> existing password on the profile update form at all times. Personally I
>> think this would be overkill, but it's not necessarily unreasonable.
>>
>> So, if anyone who knows more about this old "cookieLogin" check thinks
>> it still needs to be in the code, please say so.
>>
>> -- Allen
>>
>
>
--
http://raibledesigns.com
