Ticket #7248 (closed Bug: fixed)
auth_cookie_length doesn't take affect in Plone 3.0
| Reported by: | frawie | Owned by: | garbas |
|---|---|---|---|
| Priority: | major | Milestone: | 3.3 |
| Component: | Infrastructure | Keywords: | TuneUpDec5, tocommit |
| Cc: | csenger, frapell, bleicher |
Description
Plone 3.0.1: Setting auth_cookie_length(/portal_properties/site_properties) higher than 0 doesn't have any affect. Each User has to login again and again.
In Plone 2.5.x auth_cookie_length was working well.
Frank
Attachments
Change History
comment:3 Changed 3 years ago by bleicher
Reproduced it on plone3.2 svn on 2008-10-24
ac has Session lifetime, whatever auth_cookie_length is set to
./src/Plone/Products/CMFPlone/skins/plone_scripts/setAuthCookie.py seems not to be called
comment:5 Changed 3 years ago by csenger
- Cc csenger added
Some things I found out during debugging this. But I don't know how to fix it correctly or write a test or migration for it. PAS/PlonePAS is to complex.
The "Extended Cookie Auth Helper" (acl_users.credentials_cookie_auth) contains the code that calls setAuthCookie in Products.PlonePAS.plugins.cookie_handler.ExtendedCookieAuthHelper.updateCredentials()
ExtendedCookieAuthHelper.login() is called during login, that calls PluggableAuthService.updateCredentials (Products.PluggableAuthService.PluggableAuthService.PluggableAuthService.updateCredentials() and that calls all registered "Update Credentials Plugin"'s updateCredentials()-Methods (ICredentialsUpdatePlugin).
Workaround
In a fresh Plone 3.1 installation only session is activated as an Update Credential Plugin (acl_users->plugins->Update Credentials Plugins). ExtendedCookieAuthHelper isn't.
If you activate credentials_cookie_auth and leave it below session, an expiraton date is set for the cookie, but login does not work like in the Description of this ticket. Push it to the top, you get an expiration date for the cookie and login seems to work.
Why isn't credential_cookie_auth plugin activated?
Products.PlonePAS.Extensions.Install.setupAuthPlugins is called during setup without setting deactivate_basic_reset=False.
def setupAuthPlugins(portal, pas, plone_pas, out,
deactivate_basic_reset=True,
deactivate_cookie_challenge=False):
[...]
if deactivate_basic_reset:
disable=['ICredentialsResetPlugin', 'ICredentialsUpdatePlugin']
else:
disable=[]
activatePluginInterfaces(portal, 'credentials_cookie_auth', out,
disable=disable)
Changed 3 years ago by nueces
-
attachment
auth_cookie_length.patch
added
red the auth_cookie_length from the portal_properties / site_properties and set the expires value in the cookie session
comment:6 Changed 3 years ago by nueces
- Owner changed from bleicher to nueces
- Status changed from assigned to new
- Cc frapell added
Plone 3.X use plone.session to manage session cookies but this not read the value of auth_cookie_length in the portal_properties/site_properties. This patch implement the lost functionality. I've worked with Franco Pellegrini (frappel) in this bug.
comment:7 Changed 3 years ago by gabdavhp
- Owner changed from nueces to calvinhp
- Keywords forqa added; greenbelt removed
comment:9 Changed 3 years ago by csenger
I don't have a solid knowledge of [Plone]PAS, so the following are some random thougths.
plone.session is not a plone-specific package. The README say's it's a session management for Zope sites. Accessing self.portal_properties.site_properties in a non-plone environment may throw an exception.
Also the interface for ISessionPlugin.setupSession says:
""" Start a new session for a userid. The session will last until PAS indicates that the user has logged out. """
Maybe there is a better place in the PAS-Stack, and maybe setAuthCookie.py has to be deprecated.
comment:10 Changed 3 years ago by calvinhp
- Keywords TuneUpNov14 added; TuneUpOct24, forqa, forcommit removed
- Owner calvinhp deleted
csenger has a valid point especially since this isn't a plone.app product. The plone namespace is for items that can be used outside of the Plone the product code so relying on the portal properties tool isn't reliable here. Also, you should be getting the tools using getToolByName if you were going to do such a thing.
comment:14 Changed 3 years ago by garbas
- Keywords TuneUpDec5, tocommit added; TuneUpDec5 removed
since there is no plone.app.session i rework nueces patch. see it above it with the name auth_cookie_length.patch_v2
i'll create tests, but first i'd like to hear from others if this is the way to go. or we should create plone.app.session for this?
above fix is no doubt only ment to be temporary and should go away in future versions, but until then i think we can allow this. maybe i'm not the person to judge, since i dont know which other non-plone-projects are using plone.session
comment:15 Changed 3 years ago by wichert
There is no need for any change in !PlonePAS, or a Plone dependency in plone.session.
It should be trivial to make make the plone.session plugin a PropertyManager and add a property to control the session lifetime, with the current behavior as default.
comment:16 Changed 3 years ago by garbas
you mean something like this? (see patch v3)
i guess you also wants some tests right? :) how can i access cookies with zope.browser or any other test suite? i would need some help here
comment:17 Changed 3 years ago by wichert
Indeed. I would change the naming though: that property has nothing to do with the length of the cookie, it only effects its lifetime.
comment:18 Changed 3 years ago by garbas
like this (v4)?
comment:19 Changed 3 years ago by wichert
Like that. Now all that is missing is the test!
comment:20 Changed 3 years ago by garbas
this i think should do, right? (v5)
comment:21 Changed 3 years ago by wichert
Almost there! Currently you are testing two different things in a single test method. Please split the tests for lifetime==0 and lifetime!=0 into two separate methods.
comment:22 Changed 3 years ago by garbas
hmm dont know if i understand you correctly. is now ok (v6)
comment:23 Changed 3 years ago by wichert
- Status changed from assigned to closed
- Resolution set to fixed
comment:24 Changed 3 years ago by wichert
comment:25 Changed 3 years ago by wichert
Please note that there is a possible usability problem with this approach, which I have added to the README: the cookie lifetime is set when the session is initialised, which happens at login. That means that even though the user is active his session can suddenly stop to work. In technical terms: we are setting a session timeout, not an idle timeout.
An alternative approach would be to reset the cookie every time it is validated. This may negatively affect caching though.
comment:26 Changed 3 years ago by ruddo
Also, very important, Step 2 in this linked article still needs to be documented somewhere, otherwise the session WITHIN ZOPE will still be expired. The session timeout for this one, however, is autorefreshed every time the authenticated user hits a page, so it's not a problem:
Step 2, people. Step 2. Has to be documented or has to be overridden in a future version of this patch.
comment:27 Changed 3 years ago by ruddo
Where is the property documented? I cannot find a reference in the plone docs that tells me how to configure the cookie lifetime!
comment:28 Changed 3 years ago by ruddo
I found it in path_to_my_portal/acl_users/session/manage_propertiesForm -- this should be *documented* somewhere. And I reiterate, the session expire time in minutes for the zope server must also be changed, otherwise the server-side sessions will expire before the user cookie expires itself, and then you have a big problem.
comment:29 Changed 3 years ago by ruddo
I can confirm the bug has been fixed.
comment:30 Changed 3 years ago by hannosch
- Component changed from Login and registration to Infrastructure
