search

gorhill / uMatrix

uMatrix: Point and click matrix to filter net requests according to source, destination and type
GNU General Public License v3.0
4.56k stars 472 forks source link

prevents proper handling of 302 by Chrome #965

Closed cajopa closed 6 years ago

cajopa commented 6 years ago

Trying to access a company intranet website (not publicly available). It uses a 302 redirect to bounce the client after authentication. With uMatrix enabled, regardless of rules or even if it is enabled for the site, the browser receives the 302 and does not redirect. When I disable the uMatrix extension, it loads properly.

The redirect location takes the form of https://a.b.com/login/?next=https://a.b.com/something/, which I can see in Developer Tools; the browser simply fails to handle the 302 by making a second request to the new location.

Two cookies are employed, csrftoken and sessionid, but as mentioned, the issue is exhibited regardless of rules. I have eliminated the possibility of the issue being as an interaction with another extension by disabling all other extensions.

This seems to be a recent development - this behavior did not present in Oct 2017

OS: Windows 7 Pro SP1 Browser: Chrome v64.0.3282.186 uMatrix v1.3.2

gorhill commented 6 years ago

Be sure it's not related to #912.

cajopa commented 6 years ago

This does not appear to be related to #912: there is no garbling and there are no iframes. I am using HTTPS though can't test whether it occurs with HTTP, since I am using the SPNEGO plugin for nginx, and it only functions with SSL on. Request and response data below.

General

Request URL:https://auth.xxx.com/ Request Method:GET Status Code:302 FOUND Remote Address:209.86.xxx.xxx:443 Referrer Policy:no-referrer-when-downgrade

Response Headers

Connection:keep-alive Content-Type:text/html; charset=utf-8 Date:Tue, 06 Mar 2018 23:02:24 GMT Location:https://auth.xxx.com/user/login?next=https://auth.xxx.com/ Server:nginx/1.12.2 Set-Cookie:sessionid=; expires=Thu, 01-Jan-1970 00:00:00 GMT; Max-Age=0; Path=/ Transfer-Encoding:chunked WWW-Authenticate:Negotiate oYGxMIGuoAMKAQChCwYJKoZIgvcSAQICooGZBIGWYIGTBgkqhkiG9xIBAgICAG+BgzCBgKADAgEFoQMCAQ+idDByoAMCAReiawRpDl1tK8FGwCM8h/bYFMkr10BVaiss3uOI7Ty2ArOmi/9CAKtRZ3gT5P1NnhSxPFn0pZBFQSXm1I96hNGdLlcvVepxrZcvMj6wutPJrksiNUfSRKWTVddKL4JhTTGTe7I0FslBHT3+o94= X-Frame-Options:SAMEORIGIN

Request Headers

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8 Accept-Encoding:gzip, deflate, br Accept-Language:en-US,en;q=0.9 Cache-Control:no-cache Connection:keep-alive Cookie:csrftoken=K8arK0kKyMEQCWEUFeq2AftL4og2jC5G; sessionid=2jsiguxaiewwz84tks3m7153h8d40gj2 DNT:1 Host:auth.xxx.com Pragma:no-cache Upgrade-Insecure-Requests:1 User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36

gorhill commented 6 years ago

does not appear

I want you to try the workaround before concluding it's not related. Also, I do not see you mentioning looking at the logger. Did you? Since it's an issue on your side which nobody can reproduce, only you can investigate this. uMatrix merely enforces your ruleset, use the logger to investigate what uMatrix does internally.

cajopa commented 6 years ago

My apologies - I actually did see the workaround mentioned, but forgot to try it. I just tried it, and it seems to address the issue completely.

Also, I did take a look at the logger before submitting this bug and didn't learn anything new, so didn't mention it, to reduce noise. It just showed that the initial request occurred, which from the Dev Console I knew resulted in a 302 as expected, but then that no subsequent request was made by the browser in response. A couple cookie records appeared after that, and then nothing.

Anyway, since the workaround worked, I'm closing this bug report. Thank you for your help.

uBlock-user commented 6 years ago

It's a bug in Chrome, which got patched in v66. Use workaround setting untill v66 hits stable in April.