Opened 9 years ago
Closed 6 years ago
#1088 closed defect (bug) (worksforme)
WordPressCookies-0.1 doesn't deal with bad cookies
Reported by: | dd32 | Owned by: | |
---|---|---|---|
Milestone: | Priority: | low | |
Component: | Trac | Keywords: | |
Cc: |
Description
I'm not sure how it happened, but my wporg_logged_in
cookie became invalid, which blocked me from accessing Trac.
Trac was throwing up the following errors:
ProgrammingError: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '%s' at line 1")
which was coming from
File "/usr/local/lib/python2.7/dist-packages/WordPressCookies-0.1-py2.7.egg/wpcookies/auth.py", line 84, in _get_user_pass cursor.execute("SELECT user_pass, user_email FROM " + conn.quote(table) + " WHERE user_login = %s", username)
Upon inspecting my cookies, they were in the form of:
wordpress_test_cookie=WP+Cookie+check; wporg_sec=%7C<timestamp>%7C<hash>; wporg_logged_in=%7C<timestamp>%7C<hash>;
Note, that they specifically didn't include my username (once again, no idea how).
I guess the WordPressCookies Trac package needs updating to break early when the cookie exists, but has a blank username field.
I've seen similar reports to this in the past, and clearing cookies has always been the answer. Where the cookie gets set without a username is a question I don't think will be easy to find :)
Note: I don't know where the source of the WordPressCookies package is from, or if it's open-sourced.
@duck_ wrote WordPressCookies and I made some tweaks to it. I don't know if the source currently sits anywhere other than in the deploy repo. There's no harm in having it open.
This sounds to me like a bug in bbPress, probably, causing such a malformed cookie. If this happened in WordPress, I believe we would have heard about it.
We should indeed handle it in the plugin, though. A malformed cookie should not trigger an error like that.