Closed (won't fix)
Project:
Session API
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
24 Feb 2013 at 11:40 UTC
Updated:
13 Sep 2013 at 14:08 UTC
Jump to comment: Most recent file
Comments
Comment #1
jbrown commentedHere's the patch.
Comment #2
jhedstromPatch looks reasonable, but I'd like some other folks to test this out prior to committing.
Comment #3
jbrown commentedThe Persona project is no longer using Session API, but I think the patch is important.
It isn't possible to determine if cookies are enabled on the first request and I'm not clear on why it matters that it is being checked for.
Maybe this patch could be commited and then left in the dev release to see if it causes any problems?
Comment #4
a.ross commentedThis patch will cause test breakage, as
session_api_get_sid()must return FALSE whensession_api_available()returns FALSE.Comment #5
a.ross commentedI'm not opposed to the documentation line you added, as developers should be informed about this issue. But the code change cannot be right, as that means the module will start returning Session IDs even when it cannot be guaranteed that clients will be identified by them (IE cookies are disabled).
If it turns out that cookies are disabled, you will want to drop the bogus Session ID and let modules using Session API know it's invalidated. But how will you figure out a subsequent request belongs to the person you just tried and failed to create a Session ID for?
Comment #5.0
a.ross commentedRemoved trailing semi-colon from URL which would make it not link properly.