Occasionally, login will fail, returning no error message and without apparent cause. Unfortunately, no other information is known on this issue at this time. Rebooting the browser seemed to fix the problem, even when rebooting the server did not, so it might have something to do with the session string.
Created attachment 328406 [details] [diff] [review] Changes the path for the cookies to the highest-level domain of the site Before, no paths were set for cookies, which led to trouble with removing cookies and switching localizations. This patch ensures all cookies are sent with the proper path, so that all cookies have the same path regardless of page or localization.
Attachment #328406 - Flags: review?(clouserw)
Comment on attachment 328406 [details] [diff] [review] Changes the path for the cookies to the highest-level domain of the site 1) You assume this isn't running on SSL when you determine your cookie path. I know we talked on IRC but let's just hardcode this to '/'. It's fine to have the cookie from the root. 2) If a person doesn't have a session you're setting the value to '-'. I think you said that's how jToolkit did it but is there a good reason? Setting it to "" would delete the cookie from the client which seems cleaner to me.
Attachment #328406 - Flags: review?(clouserw) → review-
Created attachment 328518 [details] [diff] [review] Improvement upon previous cookie patch Same as previous patch, but path is always '/', the cookie is now set to '' when we want to remove the login, and expires is set to POSIX time 1 on that remove-login cookie.
Attachment #328518 - Flags: review?(clouserw) → review+
This is in revision 7735. Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.