is there a reason why PL doesn't clear its cookie on logout?
firebus - October 26, 2007 - 00:39
| Project: | Persistent Login |
| Version: | 5.x-1.3 |
| Component: | Miscellaneous |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
i have a round about reason, involving boost, for wanting to remove the PL cookie on logout.
is there a specific reason that the cookie is not deleted? or is just left there because there's no reason not to take it away once the session is destroyed on logout? (i suspect there's a little extra processing of that cookie on each page load when that cookie exists but doesn't map to a real session...)
thanks!
#1
i noticed that bjaspan had a comment on one of the issues in the boost queue, so i thought i would explain my use case.
using PL with boost, users who arrive at the site with PL cookie are not logged in, because boost looks for its DRUPAL_UID cookie which does not yet exist.
however, when the user clicks on login they are automatically logged in as boost does not cache the user page.
also if the user goes to a page with a query string (the second page of a node with comments for example) the user will suddenly be logged in.
i got a lot of complaints about this from my users.
it's easy to fix. i added the PL cookie to boost's .htaccess in a RewriteCond. now users get logged right in if they have a PL cookie.
but this creates a new problem. if the user logs out, there's still a PL cookie, and they can't browse the cached pages on the site as an anonymous user.
for now i've modified boost's hook_user('logout') function to remove the PL cookie on logout. however, if there's no benefit to keeping the PL cookie on logout, it would be cleaner to delete it in the PL module instead.
#2
There is no reason for PL not to clear its cookie, your analysis with boost is correct, and I'll fix this in PL when I can. Thanks.
#3
here's a patch against 5.x-1.2. i added a single line to _persistent_login_invalidate()
#4
Fixed in 1.4-beta2.
#5
Automatically closed -- issue fixed for two weeks with no activity.