New issue
Advanced search Search tips

Issue 635003 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Aug 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

URL parsing error caused by a specific GET parameter

Reported by a...@sched.org, Aug 5 2016 
Chrome Version       : 54.0.2819.0 (Official Build) canary (64-bit)
URLs (if applicable) : https://www.linkedin.com/uas/oauth2/authorization?scope=r_basicprofile+r_fullprofile+r_emailaddress+r_network&state=c0133f601a97a323887b219edef8f2f7&client_id=mUfaAGdi-CaK43cZu8ZbUC5zSa79eFkjkpOFttds5hCQPHkoxiYqgLewZKabcJ6i&redirect_uri=https%3A%2F%2Fsched.org%2Fconnect%2Flinkedin%3Fsuccess&response_type=code

Other browsers tested:
     Safari: OK 10.0 (12602.1.43)
    Firefox: OK 48.0b6
         IE: OK 11.0.9600.18378

What steps will reproduce the problem?
(1) Enter the URL above
(2) Hit enter
(3) URL gets misinterpreted as http://linkedin/?success&code=AQQsThNr_AiIrzQ_cmEZk_Eh9mwyBVLTysdnURlK0HH2w3uSSeU-kmD3AOOd5f1dDMMd5VIfA03QihExhw-MCJ5t_c5ylTGVD6WfgwMKaBVC-QH6m44&state=c0133f601a97a323887b219edef8f2f7#!

What is the expected result?
Correct interpreting of the URL (as entered).

What happens instead?
Part of the "redirect_uri" GET parameter gets interpreted as the beginning of the URL.

Please provide any additional information below. Attach a screenshot if
possible.
The issue is somewhere in the "client_id" parameter - if i remove it, the URL gets parsed just fine. Note that this only happens with *this particular* value for the "client_id". Other values thus far worked fine. Also, note that URLencoding the value does not help.

This issue was reported to us by our customer, who couldn't connect his LinkedIn profile to our app, and was kind enough to provide the request URL. This is the only instance of this happening that was ever reported to us.
Screen Shot 2016-08-05 at 19.59.32.png
156 KB View Download

Comment 1 by nhar...@chromium.org, Aug 5 2016

Status: WontFix (was: Unconfirmed)
I was able to reproduce this bug, and it appears to be an issue with how sched.org handles the request to https://sched.org/connect/linkedin/?success&code=AQQsThNr_AiIrzQ_cmEZk_Eh9mwyBVLTysdnURlK0HH2w3uSSeU-kmD3AOOd5f1dDMMd5VIfA03QihExhw-MCJ5t_c5ylTGVD6WfgwMKaBVC-QH6m44&state=c0133f601a97a323887b219edef8f2f7

I see the following request/response headers for that request:

GET /connect/linkedin/?success&code=AQQsThNr_AiIrzQ_cmEZk_Eh9mwyBVLTysdnURlK0HH2w3uSSeU-kmD3AOOd5f1dDMMd5VIfA03QihExhw-MCJ5t_c5ylTGVD6WfgwMKaBVC-QH6m44&state=c0133f601a97a323887b219edef8f2f7 HTTP/1.1
Host: sched.org
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8


HTTP/1.1 302 Moved Temporarily
Date: Fri, 05 Aug 2016 19:29:21 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: [119 bytes were stripped]
Set-Cookie: [100 bytes were stripped]
Set-Cookie: [30 bytes were stripped]
Location: http:///linkedin?success&code=AQQsThNr_AiIrzQ_cmEZk_Eh9mwyBVLTysdnURlK0HH2w3uSSeU-kmD3AOOd5f1dDMMd5VIfA03QihExhw-MCJ5t_c5ylTGVD6WfgwMKaBVC-QH6m44&state=c0133f601a97a323887b219edef8f2f7
Vary: User-Agent
Content-Length: 0
Content-Type: text/html
Strict-Transport-Security: max-age=0


To me, this looks like a bug in how sched.org is handling that url, not a bug in how Chrome parses URLs.

Comment 2 by a...@sched.org, Aug 5 2016 

Ah, possible/probable.

Although, i don't get why this is the only output i get in the dev tools Network tab (attached).
Screen Shot 2016-08-05 at 21.44.26.png
130 KB View Download

Comment 3 by a...@sched.org, Aug 5 2016 

Nevermind, got it. Apparently, Preserve Log doesn't work for me when Dev Tools are started from a blank tab in Canary, and only shows the blank tabs requests (i.e. it behaves as if the subsequent URLs opened are new/separate tabs).

Sorry for the confusion.
►

Sign in to add a comment