Remember me feature does not work

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

The remember me feature does not work at all:

1/ Even if I ask firefox to remember my credentials on the login page, I have to type the user and password every time I want to login
2/ Even if I click on remember me, I have to login if I am inactive for 20-30 minutes
3/ Sometimes the left upper sidebar shows my user name, I click on a page it dissapear, I click on another page and it's back again

Other users using this instance have the same problem with other Browser/OS combination.

Hint: the logs show the following when I need to login again.

[TP-Processor7] INFO  org.codehaus.plexus.security.ui.web.util.AutoLoginCookies  - Invalid AuthenticationKey 
37af9828d89c45d39d5e3f46a15e5b63 submitted. Invalidating cookie.
[TP-Processor7] WARN  JPOX.RDBMS.SQL  - Object with id "37af9828d89c45d39d5e3f46a15e5b63" not found !
[TP-Processor7] INFO  org.codehaus.plexus.security.ui.web.util.AutoLoginCookies  - Invalid AuthenticationKey 
37af9828d89c45d39d5e3f46a15e5b63 submitted. Invalidating cookie.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. CONTINUUM-1196 Does not display proper information when user returns to site

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jesse McConnell added a comment -

http://jira.codehaus.org/browse/CONTINUUM-1196 also has some interesting connections

Show
Jesse McConnell added a comment - http://jira.codehaus.org/browse/CONTINUUM-1196 also has some interesting connections
Hide
Permalink
Jesse McConnell added a comment -

I am unable to validate this behavior right now...I'll have to try some other browsers maybe, but it works correctly for me..

if you could try the latest snapshots and verify it is still an issue for you that would be stellar

Show
Jesse McConnell added a comment - I am unable to validate this behavior right now...I'll have to try some other browsers maybe, but it works correctly for me.. if you could try the latest snapshots and verify it is still an issue for you that would be stellar
Hide
Permalink
Jesse McConnell added a comment -

the source of this bug is in the ContinuumActionSupport, it has a prepare interceptor being called before the autologin interceptor...this forces a variable to be null and fails the necessary authorization checks on the action the first time it is renders...

so its a configuration issue, fixing it now

Show
Jesse McConnell added a comment - the source of this bug is in the ContinuumActionSupport, it has a prepare interceptor being called before the autologin interceptor...this forces a variable to be null and fails the necessary authorization checks on the action the first time it is renders... so its a configuration issue, fixing it now
Hide
Permalink
Jesse McConnell added a comment -

the security setup on continuum stems from the ContinuumActionSupport
class which is the parent to most actions in continuum. it is also where
all of the authz goop is abstracted away too, and it uses the prepare
interceptor to put the securitySession of the user into action. Well
the xwork interceptor stack was setup so that this happened before the
autologin interceptors were calls, which in effect made the first
page on the autologin path fail the authorizations of that action...

this was masked because once that other interceptor ran it was all setup to
go so jsp's rendering on the page actually had the relevant information
available.

moral of the story, get your interceptor stack in order...

Show
Jesse McConnell added a comment - the security setup on continuum stems from the ContinuumActionSupport class which is the parent to most actions in continuum. it is also where all of the authz goop is abstracted away too, and it uses the prepare interceptor to put the securitySession of the user into action. Well the xwork interceptor stack was setup so that this happened before the autologin interceptors were calls, which in effect made the first page on the autologin path fail the authorizations of that action... this was masked because once that other interceptor ran it was all setup to go so jsp's rendering on the page actually had the relevant information available. moral of the story, get your interceptor stack in order...

People

  • Assignee:
    Jesse McConnell
    Reporter:
    Stéphane Nicoll
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: