Option `persistent_sessions` is not working in `0.4dev-r10747`

There are actually a number of reasons, why this could fail.

At first thanks for mentioning exact versions you've been testing with. That's not commonly expected here on average, but highly appreciated.

I didn't understand, if it failed with both test setups, or was at least correctly in the first one.?

The remember-me box is there, so your configuration is effective. Good thing.

To understand more about the failure, you should make sure, that your browser still has the required session cookie after restart. I know there are browser settings to "forget" cookies on every application closure, even if that's not the default for IE as I guess.

If so, we'll look at the server side. This will require looking at the log in DEBUG mode and at Trac db tables auth_cookie and session.

Replying to hasienda:

At first thanks for mentioning exact versions you've been testing with. That's not commonly expected here on average, but highly appreciated.

No Problem. It's me who has the problem and wants a solution ...

I didn't understand, if it failed with both test setups, or was at least correctly in the first one.?

In the first setup with version 0.3 it worked.

To understand more about the failure, you should make sure, that your browser still has the required session cookie after restart. I know there are browser settings to "forget" cookies on every application closure, even if that's not the default for IE as I guess.

How do I check this? Just FYI: I tested it with IE9, but my collegue is using Firefox and there it is not working either.

If so, we'll look at the server side. This will require looking at the log in DEBUG mode and at Trac db tables auth_cookie and session.

I had already a quick look at the logs (I have DEBUG mode on my test system) and there wasn't anything suspisious - yet I don't know after what I should look ...

Replying to framay:

Replying to hasienda:

I didn't understand, if it failed with both test setups, or was at least correctly in the first one.?

In the first setup with version 0.3 it worked.

To understand more about the failure, you should make sure, that your browser still has the required session cookie after restart. I know there are browser settings to "forget" cookies on every application closure, even if that's not the default for IE as I guess.

How do I check this? Just FYI: I tested it with IE9, but my collegue is using Firefox and there it is not working either.

This is good news. NOT hunting browser-specific bugs is always a good thing.

If so, we'll look at the server side. This will require looking at the log in DEBUG mode and at Trac db tables auth_cookie and session.

I had already a quick look at the logs (I have DEBUG mode on my test system) and there wasn't anything suspisious - yet I don't know after what I should look ...

Let me have a look at the changes between these versions. I should come up with more specific questions then, not to stress debug logging and you too much. Still, should you find something suspicious later on, just tell me, please.

Hi!

I am able to confirm the problem posted by framay. While it was working in version 0.3 (in combination with Trac 0.12), the current 0.4dev version of the AccountManagerPlugin causes the persistent_sessions option to have no effect at all.

I tried different browsers with the least-restrictive settings concerning cookies. After closing the browser window, opening it again with the trac website, the user is no longer authenticated.

As you seem to look into the problem right now, please let me know if you need any further information that may be helpful to solve the problem. Thanks!

JCD

Diff for adding debug info

When applying web_ui_9547.py.diff the outcome in my log file is as following:

cookie_path: /trac, lifetime: 0

When setting it as following in trac.ini it works:

auth_cookie_lifetime = 2592000

Replying to framay:

When setting it as following in trac.ini it works: {{{ #!ini auth_cookie_lifetime = 2592000 }}}

I can confirm this -- adding the auth_cookie_lifetime setting fixes the problem for me also.

Ok, that you all for confirmation.

Seems like a systematic fault rather then a spurious effect. The full revision-spanning diff didn't yield immediately perceptible suspicious changes. I hope to to more systematic debugging soon, because the scope is already rather narrowed down thanks to your investigations.

(In [11086]) AccountManagerPlugin: Ensure sensible browser cookie lifetime setting, refs #8927, #9088, #9095, #9099 and #9547.

I think this is now the most intuitive setting of default cookie lifetime: auth_cookie_lifetime from section [trac] gets overwritten with AcctMgr default (30 d) as long as it's found equal to the Trac default (0).

Remember, that the AcctMgr feature still has to be switched on with the boolean option persistent_sessions, that defaults to False, if unset.

Looking forward to getting positive response after what seems like an odyssey of getting [10169] right.

And sorry for the inconvenience caused by introducing such a simple feature.

(In [11100]) AccountManagerPlugin: Refresh cookie value, refs #9088 and #9547.

New option cookie_refresh_pct determines, how often cookie ID's will get changed on average.

(In [12398]) AccountManagerPlugin: Releasing version 0.4, pushing development to acct_mgr-0.5dev.

Availability of that code as stable release closes #874, #3459, #4677, #5295, #5691, #6616, #7577, #8076, #8685, #8770, #8791, #8990, #9052, #9079, #9090, #9139, #9246, #9252, #9547, #9618, #9676, #9843, #9852, #9940, #10023, #10028, #10123, #10142, #10204, #10276, #10397, #10412, #10594, #10625 and #10644.

Some more issues have been worked-on, yet without confirmed resolution, refs #5464 (for JiraToTracIntegration), #8927 and #10134.

And finally there are some issues and enhancement requests showing progress, but known to require more work to resolve them satisfactorily, refs #843, #1600, #5964, #8217, #8933.

Thanks to all contributors and followers, that enabled and encouraged a good portion of this development work.