Issue metadata
Sign in to add a comment
|
Chrome 66: Redirecting URL to get Images and Photos stored outside current App (SharePoint)
Reported by
nikkota...@gmail.com,
May 17 2018
|
||||||||||||||||||||||||
Issue description
Chrome Version : 66.0.3359.139
O/S Version: : Windows 7 and Windows 10
URLs (if applicable) : Any in our sharepoint apps - different platforms
Other browsers tested: IE 11, Edge, Firefox, Safari
Add OK or FAIL after other browsers where you have tested this issue: Only fails on Chrome version 66 - worked on all previous chrome version and works on all other browsers tested
Safari: works fine
Firefox: works fine
IE/Edge: works fine
What steps will reproduce the problem?
1. In SharePoint - have a list column point to an image URL in another web app (such as another URL or user profile photos
2. If you have browser set to always prompt - when the page loads - chrome is not only prompting for credentials for the web app with the images but also redirecting you there - when the URL should never change or redirect. Only occurs in Chrome 66.
What is the expected result?
After the authentication box for credentials - the images should just load on the page.
What happens instead of that?
Chrome 66 is not only prompting for credentials as it should but it's actually redirecting to those URLs. Example is if main URL is Intranet.company.com and photo's started in MyPhotos.company.com
Please provide any additional information below. Attach a screenshot if
possible.
Detail Summary:
When browser security is set to prompt for credentials (instead of automatic logon), any images (like user photo's or any images/pictures) that are stored outside the current web application (like intranet.mydomain.com for the main site and mysite.mydomain.com for the images/photos), Instead of Chrome just prompting for credentials like it always used to do - it is now also Re-directing to that URL too - causing a lot of confusion- and then users have to log in and then use the back button and refresh button to get the page to load with the images. Both URLs are set to NTLM authentication. Prompting for authentication is fine - but we should not be redirected suddenly to obtain the image files. Many have browsers set to auto-logon but many don't/can't.
We have tested this in all of our environments in both SharePoint 2013 and SharePoint 2016 from DEV, FTE, UAT, and PROD and it all broke and started redirecting with Chrome 66. We have tested re-installing chrome version 58-65 and the functionality works fine in them, but version 66 started this trouble for our web sites with constant redirection to a site to authenticate to get the images instead of just showing the authentication box to provide credentials before just displaying the images with the page.
Note: It may not be sharepoint specific but the issue with redirecting to a URL to obtain images or profile pictures always is redirecting to the URL instead of just authenticating and displaying the image files like it did in all chrome versions prior to version 66
,
May 17 2018
I don't believe this issue is related to SharePoint. I did find another report of a change in NTLM behavior here: https://stackoverflow.com/questions/50268590/making-an-api-request-to-a-ntlm-authenticated-server-in-chrome-66 We are seeing similar behavior with our intranet application. Ours makes a cross-site XmlHttpRequest to a RESTful service to authenticate the user with NTLM. If the implicit credentials from the Windows session work, all is good. If they don't, the login prompt appears, but the page context in the address bar becomes the URL of the authentication service. The user sees an empty page while all this is happening, and stays on an empty page (the auth URL) after valid credentials are entered. At that point, navigating back does take you to the application URL and you are successfully logged in, but that is not the end user experience we're looking to provide. Prior to Chrome 66, the login prompt would be shown with the URL of the authentication service, but the page context would not be changed. This remains the behavior in latest versions of Edge and Firefox. Very interested in seeing this fixed, but there are obvious difficulties in setting up a test case for you to reproduce. I'm happy to provide more details if you need them. Thanks for taking a look.
,
May 18 2018
nikkotasha@ - Thanks for filing the issue...!! Could you please provide a sample url to test the issue from TE-end. As navigating to the url: https://stackoverflow.com/questions/50268590/making-an-api-request-to-a-ntlm-authenticated-server-in-chrome-66 provided in comment#2, does nothing and creates only a blank page. Thanks...!!
,
May 18 2018
Again, I don't think this can easily be set up with a public URL, since it involves NTLM authentication. I can give you a pretty simple test case which I ran in Windows 7 but should also work in 10, assuming IIS is installed and working. With default installation of IIS on the machine, add C:\inetpub\wwwroot\test.html as follows, replacing mymachine with the appropriate hostname. <html> <body> <div> Here is some text. <img src="http://mymachine:3333/test.jpg" style="width: 50;"/> Here is some more. </div> </body> </html> In IIS Manager, create a new site called Test with physical path C:\inetpub\test. Under binding, set port to 3333. Hit OK to create the site. Edit IIS Authentication settings. Enable Windows authentication and disable Anonymous. Copy a jpg image file to C:\inetpub\test\test.jpg. In content view in IIS Manager, edit permissions. Under advanced, turn off inherited permissions, then remove permissions for Users group. Confirm that a visit to http://mymachine:3333/test.jpg brings up a prompt for credentials. If not, for purposes of the test, you may have to limit access to the file to a particular account, not the one you're logged in as. That's about it. When you navigate to http://mymachine/test.html in Chrome 66+, you get the prompt for the resource and the page context incorrectly becomes that of the resource URL. In Chrome 65 and Firefox 58, you get the prompt for the resource, but the page context does not change. What's interesting is that in the very latest Firefox (60), Opera, and Edge, you don't get a prompt at all anymore. The dev tools console shows a 401 for the resource, but there is no opportunity to enter credentials. That may be bad news for the original poster. But where the cross-site resource is requested via fetch or XHR, the latest versions of the other browsers still behave as expected - staying on the current page, but accepting credentials for the other site. This is what I'm hoping to see working again in Chrome.
,
May 19 2018
This is on my companies internal network (internal) - not public website so I can't provide an example URL... I made up the URL just to show you how to simulate the issue. As mentioned, I didn't believe a SharePoint specific issue so glad others are seeing same and similar issue - and for someone providing a way for others to see and simulate the same behavior outside of SharePoint. Appreciate it...
,
May 19 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 21 2018
proposed title change: NTLM-authenticated cross-site resources redirect away from page
,
May 21 2018
nasko: Could you help triage to see if it's possible that Site Isolation has any relation to the symptoms described in Comment #2?
,
May 21 2018
nikkotasha@: Can you use the steps at https://www.chromium.org/Home/chromium-security/site-isolation#TOC-Diagnosing-Issues to see if it makes the problem go away? Specifically, opt out of Site Isolation trials using chrome://flags#site-isolation-trial-opt-out and restart. We're curious if the problem still happens or not. Thanks! CC'ing meacer@, since this could potentially be related to the HTTP Auth interstitial like issue 839724 . That would only be the case if the bug shows a blank page after the "redirect" and not the image itself.
,
May 21 2018
I read up on issue 839724 mentioned above and saw that a fix was in branch M67. I picked up devchannel release 68.0.3432.3 and found that the symptoms I described here have been resolved in that release. That includes my original case of authenticating against another site with XMLHttpRequest, and the test case I made with cross-site images like the originally reported issue. Thanks very much for the quick responses, and sorry for not catching where the issue had been originally filed.
,
May 21 2018
And yes, in all symptomatic cases, only saw blank page after redirect.
,
May 21 2018
joearch4@: Thanks for confirming that this has been fixed. The description indeed matches with bug 839724 which in turn is a dupe of 840176. creis@: I'm merging this into bug 840176 but feel free to reopen if you want to further investigate from a site isolation angle.
,
May 23 2018
FYI.. No site isolation opt-out does not appear to resolve the issue. I tried that last week and just tried again - and still redirects. I'm confused as someone says this issue has been fixed (...fix was in branch M67. I picked up devchannel release 68.0.3432.3( - but I know we downloaded and tried both beta (version 67) and canary (version 68) and both are still redirecting. If found fixes - what release would that be in to verify? Thank you!
,
May 23 2018
OK - I found how to download new canary version - and YES - it works again with that release. When will that be the published release? This is great. Thank you! |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by krajshree@chromium.org
, May 17 2018