Bug #72

POST more than two days after GET

Added by Spuds Cooks about 1 month ago. Updated 19 days ago.

Status:ClosedStart date:12/24/2013
Priority:LowDue date:
Assignee:Michael Hampton% Done:

0%

Category:-
Target version:2.2.15

Description

I've been getting this issue and tracked it down to a couple of items.

Originally on the site, the eu cookie option was not enabled, so bb2_screener_cookie was setting a cookie with the expiration time of 0 (when browser session ends)

Later the eu cookie option was enabled, so now bb2_screener_cookie does not set a cookie (as expected), however Chrome (latest version as of 12/13) still sends back the cookie. Doing a search on when browser session ends, it seems chrome has its own ideas of what that means. So the result is Chrome will continue to send back the old cookie and that will trigger the b40c8ddc error.

Possible solutions are
1) don't use 0 as the expire time on the cookie (due to the way chrome handles it) but set a valid time limit, allow that to be set in $settings and if not set then default to 0. Then the cookie will expire naturally and Chrome will not send it

2) Before using the cookie in bb2_post, check the $settings['eu_cookie'] status to make sure you should be using it at all.

History

#1 Updated by Michael Hampton about 1 month ago

  • Priority changed from Normal to Low

If Chrome is holding cookies past the end of session, this sounds like a bug in Chrome. Looks like issue 128513 which has some workarounds. This is pretty ridiculous. Oh well, another reason I don't use Chrome anymore...

I'll see what I can do to work around this absurdity.

#2 Updated by Spuds Cooks about 1 month ago

Michael Hampton wrote:

If Chrome is holding cookies past the end of session, this sounds like a bug in Chrome. Looks like issue 128513 which has some workarounds. This is pretty ridiculous. Oh well, another reason I don't use Chrome anymore...

I'll see what I can do to work around this absurdity.

I agree is a Chrome issue, actually from reading its been that way for awhile and there is no intention to change the behavior. In this case it is causing it to send back a screener cookie that is 9 months old.

I'd guess the easiest workaround from a BB view would be option 2 which is don't be using the cookie at all if its been specifically disabled, but there are many choices.

#3 Updated by Michael Hampton about 1 month ago

  • Tracker changed from Feature to Bug
  • Status changed from New to In Progress
  • Assignee set to Michael Hampton
  • Target version changed from 2.2.14 to 2.2.15

This will be fixed in the next release of Bad Behavior.

The workaround consists of two parts:

1. If eu_cookie is set, we do not use the value of any existing cookie.
2. If eu_cookie is set, we attempt to delete any existing cookie.

#4 Updated by Michael Hampton about 1 month ago

  • Status changed from In Progress to Resolved

#5 Updated by Michael Hampton 19 days ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF