unable to login with fastpath enabled
| Project: | fastpath_fscache |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Jeremy@kerneltrap.org |
| Status: | closed |
Jump to:
The fastpath logic happens before the Drupal session is loaded into memory, so in the current implementation if a page is cached we simply serve it. A user can log in, as my earlier patch doesn't serve pages from cache if $_POST is set. But as soon as you navigate to a page without $_POST set that is already cached, that will be served to the user as if they're not logged in.
The solution I used in my old version of the code was to set a cookie when user's log in.
Attached is a patch that re-implements this cookie logic. I'm posting it here without just committing it to see if anyone has a better way to do this. If I don't get any feedback in the next day or two, I'll probably just impatiently commit it so that the module is at least functional.
| Attachment | Size |
|---|---|
| fastpath_fscache.patch | 2.76 KB |
#1
well, i've wanted that cookie for a long time, but never got around to implementing it. i wanted it because if it is not present, core does not even need to query sessions table to see if user has valid session. he can just serve from cache. so this is valuable for core too.
anyway, i think yours is a reasonable solution. you'll have to be careful to assure the cookie is set for the right time and gets killed upon logout. mimic the sesion cookie, i think.
#2
Putting it in core would be less problem-prone, as then we could simply set and destroy the cookie when we set and destroy the session. But as I'm not currently interested in a solution that involves a patch to core, I've not been able to find a better way to do this. (One issue: if you allow auto-logins then the 'login' hook is never called due to a core bug. But as that's a core bug, I'm not going to worry about it.)
Cool, I'll go ahead and commit this. Thanks for looking at it.
#3
Committed.
#4
fyi, boost.module also uses a drupal_uid cookie. we'll get this into core for next release i think.
#5
I just came across a small problem with this. When you first install the module, no authenticated users have a DRUPAL_UID cookie. Thus they wrongly get cached pages. The best solution I can think of is to delete authenticated user sessions when this module is enabled. I'm committing that code now. We can adjust it if someone comes up with a better idea.
I thought about setting the cookie if not present for any logged in user on every page view. Thats fine, but the user could get a few cached pages in a row and never hit a code branch where we could set the cookie.
#6
If the user hits a cached page, the affect is the same whether or not you flush the session table. That is, either way they'll see a non-logged in page.
#7
thats true ... at least with my change they will eventually get to hook_user('login') and get the cookie they need. needs some more thought.
#8
what i meant to say is that if we don't clear sessions, the user could get a mix of logged in and logged out pages as he browses around. with my patch, he will really be logged out and will eventaully login (and thus get a cookie).
the only other approach i can think of is to cookie anon users too with uid=0. the usefulness of that only applies ot people without any cookie. when fastpath sees such a person, they refuse to send a cached page and thus we get a chance to load session info for that person, and set proper cookie. the downside of this is that the first page will always be non cached, and spiders that don't support cookies will always get uncached pages. pretty bad.
#9