spring - How to implement one controller mapping method for different scenarios -

i have spring controller method called in different scenarios. here example...

@requestmapping("/resetpassword") public modelandview resetpassword( @valid @modelattribute("resetpasswordform") resetpawdformform resetpawdformform, modelandview modelandview){ 

... method executed in 3 different scenarios....

1. using hyper link coming user reset password link sent user email.. eg: localhost/myapp/login/resetpassword// here can authenticate userid , activationsecretcode in db , let user reset password

2. user can click on resetpassword link user settings page. eg: since user coming user settings page, can validate usersession , allow him reset password

3. user can login first time successfully, forced reset password due admin requirements reset initial default password. eg: in user neither have session, nor passing activationcode validate. login method validates userid/default password , redirects resetpassword mapping(method=get).

how can system authenticate user request , allow him reset password?

one alternative is, use flash attributes , set authenticationkey flash attributes...which verified in resetpassword method.

is there other way implement this....

note: posted issue in implementing approach in post: spring: how pass java objects during redirect while using modelattribute

any help?

i think best way implement using 3 different action methods:

• resetpassword (e-mails)
• resetloggeduserpassword (via settings)
• changedefaultpassword

they may share same view, behaviors not equal, avoid overloading action responsibility.

edit: elaborating on comment:

1) secure e-mail link, 1 way add authentication token. token can weak hashed user id plus salt string, or strong guid expiration time in database table, generated whenever user requests password reset.

2) settings way not problem, considering user logged in.

3) temporary password action can secured same way 1, or same way 2, if put user on session. logging in user default password status shouldn't concern if code verify status of account inside request filter.