811639 - [train-2012.11.09] stage is not detecting {eyedee.me,mockmyid.com,delegat.es} as primaries

Status: VERIFIED FIXED

(Cloud Services :: Server: Identity, defect)

Description

[John Morrison [:jrgm]]

Hi, Gene

Something appears to be wrong with squid in the stage environment. This is what I wrote in https://github.com/mozilla/browserid/issues/2712.


>> STR
>> 
>> In stage, try to signup as a primary user (e.g., [e-mail])
>> 
>> The dialog immediately switches to the secondary flow.
>> 
>> In stage browserid.log I see {"level":"debug","message":"eyedee.me is not a browserid primary - non-200 response code to /.well-known/browserid","timestamp":"2012-11-14T07:03:55.117Z"}
>>
>> From my laptop, curl https://eyedee.me/.well-known/browserid returns a valid response for a primary with provisioning, etc.
>> 
>> The same [e-mail] addresses in either prod or dev trigger the primary flow, so this appears to be most likely a problem with squid in the stage environment. But I could be wrong.

Comment 1

[John Morrison [:jrgm]]

Sorry, more readable this time:

>> STR
>> 
>> In stage, try to signup as a primary user (e.g., [e-mail])
>> 
>> The dialog immediately switches to the secondary flow.
>> 
>> In stage browserid.log I see {"level":"debug","message":"eyedee.me is
>> not a browserid primary - non-200 response code to
>> /.well-known/browserid","timestamp":"2012-11-14T07:03:55.117Z"}
>>
>> From my laptop, curl https://eyedee.me/.well-known/browserid returns
>> a valid response for a primary with provisioning, etc.
>>
>> The same [e-mail] addresses in either prod or dev trigger the
>> primary flow, so this appears to be most likely a problem with squid
>> in the stage environment. But I could be wrong.

Comment 2

[John Morrison [:jrgm]]

I see that an attempt to make a request via 

403 with X-Squid-Error: ERR_ACCESS_DENIED. That is true for an eyedee.me email address (a primary idp), yahoo.com and fastmail.fm (secondaries).

Comment 3

[Gene Wood [:gene]]

Ok, sorry that took so long. We can't use curl to test this because curl uses a different method for proxying requests to https resources ( http://en.wikipedia.org/wiki/HTTP_tunnel#HTTP_CONNECT_Tunneling ) than how browserid proxies.

Here are the tests that I've run in stage and in prod :

Prod :

[[e-mail] ~]$ echo "import httplib
> conn = httplib.HTTPConnection('idproxy.idweb', 8888)
> conn.request('GET', 'https://eyedee.me/.well-known/browserid')
> req = conn.getresponse()
> print req.status, req.reason
> for h in req.getheaders():
>  print h
> print req.read()" | python

200 OK
('content-length', '467')
('via', '1.0 idproxy1.dmz.scl2.svc.mozilla.com (squid/3.1.10)')
('x-cache', 'MISS from idproxy1.dmz.scl2.svc.mozilla.com')
('x-powered-by', 'Express')
('accept-ranges', 'bytes')
('last-modified', 'Wed, 12 Sep 2012 22:13:09 GMT')
('connection', 'keep-alive')
('etag', '"467-1347487989000"')
('cache-control', 'public, max-age=0')
('date', 'Thu, 15 Nov 2012 23:29:04 GMT')
('content-type', 'application/json')
('x-cache-lookup', 'HIT from idproxy1.dmz.scl2.svc.mozilla.com:8888')
{
    "public-key": {"algorithm":"RS","n":"110348937096198925172556590377216823058593836386257925323505191957624367557108736999778458174863691591461052831864256055554130717903792155654910190135172094054147382667835830922954188029980616353508693118182641147805178035365026236528352020524144412106236747551027171758998687091215938756404750456869721493677","e":"65537"},
    "authentication": "/browserid/sign_in.html",
    "provisioning": "/browserid/provision.html"
}

[[e-mail] ~]$ 


Stage :

[[e-mail] ~]$ echo "import httplib
> conn = httplib.HTTPConnection('idproxy.idweb', 8888)
> conn.request('GET', 'https://eyedee.me/.well-known/browserid')
> req = conn.getresponse()
> print req.status, req.reason
> for h in req.getheaders():
>  print h
> print req.read()" | python
200 OK
('content-length', '467')
('via', '1.0 idproxy2.dmz.scl2.stage.svc.mozilla.com (squid/3.1.10)')
('x-cache', 'MISS from idproxy2.dmz.scl2.stage.svc.mozilla.com')
('x-powered-by', 'Express')
('accept-ranges', 'bytes')
('last-modified', 'Wed, 12 Sep 2012 22:13:09 GMT')
('connection', 'keep-alive')
('etag', '"467-1347487989000"')
('cache-control', 'public, max-age=0')
('date', 'Thu, 15 Nov 2012 23:28:46 GMT')
('content-type', 'application/json')
('x-cache-lookup', 'HIT from idproxy2.dmz.scl2.stage.svc.mozilla.com:8888')
{
    "public-key": {"algorithm":"RS","n":"110348937096198925172556590377216823058593836386257925323505191957624367557108736999778458174863691591461052831864256055554130717903792155654910190135172094054147382667835830922954188029980616353508693118182641147805178035365026236528352020524144412106236747551027171758998687091215938756404750456869721493677","e":"65537"},
    "authentication": "/browserid/sign_in.html",
    "provisioning": "/browserid/provision.html"
}

[[e-mail] ~]$

Comment 4

[Gene Wood [:gene]]

Here is the browserid code that renders the proxying functionality which I used to render this python tool : https://github.com/mozilla/browserid/blob/dev/lib/primary.js#L191

Comment 5

[Gene Wood [:gene]]

Just re-ran this with the new query parameter in prod and stage :

echo "import httplib
conn = httplib.HTTPConnection('idproxy.idweb', 8888)
conn.request('GET', 'https://eyedee.me/.well-known/browserid?domain=eyedee.me')
req = conn.getresponse()
print req.status, req.reason
for h in req.getheaders():
 print h
print req.read()" | python

failed in both cases. The cause : this line in the proxy config :

acl bidcert urlpath_regex ^/.well-known/browserid$

notice the "$" at the end of the regex

Comment 6

[Gene Wood [:gene]]

staging proxies are now fixed. This change will need to go to prod after it's tested. Let me know if it looks good.

Comment 7

[John Morrison [:jrgm]]

This was indeed fixed. Sorry for losing this in the spew of bugzilla messages I get.

I also know we made this config change for squid in production last week.