crash-stats.mozilla.com failed to load w/ "Disallowed key characters in global data."

RESOLVED FIXED

Status

Socorro
General
--
minor
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: Chris Beard, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

8 years ago
when i attempt to load http://crash-stats.mozilla.com in Firefox 3.6.3, it doesn't load anything and instead just displays "Disallowed key characters in global data."

it works fine in both Chrome and Safari

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Assignee: server-ops → nobody
Group: infra
Component: Server Operations → Socorro
Product: mozilla.org → Webtools
QA Contact: mrz → socorro
(Reporter)

Comment 1

8 years ago
i'm still seeing this

Comment 2

7 years ago
Chris, is this still happening? Looks like it's WFM...

Comment 3

7 years ago
Interestingly, we saw a bit of this during the datacenter migration.  I think it's caused by having some http pages in an https mix.  We're now forcing https, so I bet we don't see it any more.
I think that what changed this is when jabba disabled caching on the Zeus loadbalancer (SSL is terminated there), my guess is that some user or automated query (most likely the latter) was triggering this, and that page was getting cached (since we weren't seeing the traffic in the access logs).

We saw it after going HTTPS-only but have not since caching was disabled, I don't see a note about this in any bugs so CC'ing jabba to see if my recollection is correct.

Comment 5

7 years ago
That is correct. After disabling caching in zeus the problem has not come up again.

This doesn't mean the problem was fixed, but it does mean that if this error pops up, it doesn't get cached and take down the site.
(In reply to comment #5)
> That is correct. After disabling caching in zeus the problem has not come up
> again.
> 
> This doesn't mean the problem was fixed, but it does mean that if this error
> pops up, it doesn't get cached and take down the site.

Just to clarify, if my theory in comment 4 is right then this isn't really a bug per se it's that this function (in the external Kohana project that we use) is called for all user input (cookie or HTTP GET/POST), and does an exit() if the regex does not match : http://code.google.com/p/socorro/source/browse/trunk/webapp-php/system/libraries/Input.php#391

Here is an example:
https://crash-stats.stage.mozilla.com/query/query?query=&*

Note that this error page returns HTTP 200, making it eligible for caching, which does seem like a bug to me; Kohana should probably be setting the HTTP status code to 500 or so. It looks like Kohana has been completely rewritten so not sure if we can submit a patch for this, but we could take it in our copy if we want.

My guess is that what happened is that some script or user (likely trying some kind of attack) was setting cookies to strange things, and would cause the error page to be cached. This would explain why we never saw anything in the access logs when this problem was reported.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.