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.
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.
-- 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
