I am developing a Drupal site, within which is a page with an iframe, displaying an external SQL Reporting server driven site.
This iframed site is protected on by HTTP authentication. In all browsers, apart from Chrome, when the page is viewed, the browser driven login box pops up.
In Chrome (Windows & OS X), no login box appears and I get an immediate 401 error from the SQL Reporting Server. I've cleared cache's and even tried on a fresh chrome installation on a VM.
The above method works fine on the clients existing live site, which is ASP driven. Other than CMS technology, the only other obvious difference is domains.
The working live site is referencing a sub domain of itself in the iframe. The development site is referencing a completely different domain.
I've tried /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome -–allow-cross-origin-auth-prompt, which seems to make no difference.
Does Chrome have much tighter cross domain login rules? Or am I missing something else?
According to the devs at chromium, this was an intentional change to protect against phishing attacks. If you say the prod sites reference the same domain, you shouldn't have any issues.
http://code.google.com/p/chromium/issues/detail?id=91814
To switch the (in my mind stupid) security-feature off set Browser flag:
--allow-cross-origin-auth-prompt
In Linux close all Browser Instances and type in terminal:
chromium-browser --allow-cross-origin-auth-prompt
For Windows, Mac, Android... take a look here: http://www.chromium.org/developers/how-tos/run-chromium-with-flags
See http://www.chromium.org/administrators/policy-list-3#AllowCrossOriginAuthPrompt for the policy that can be set versus using flags.
On Windows this can be set via the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. See http://www.chromium.org/administrators/policy-templates for more information.
Related
Now we build a site with sharepoint 2013. Per our customer requirement, we need to support IE8. But my develop environment is IE11(in windows server 2008R2), so I decide to degrade my IE version.
In the beginning, I can use IE11 to access the website which I created in share point. But after my degrading operation, strange things happened: I enter the url in the IE8, it is loading... seems every thing is fine, I can see the background pictures be downloaded in the browser,but few seconds when it loading completes(I guess), it redirects to the 404 error page.(normal page flash to the 404 error page) And I tried to use Chrome to visit this site, every thing works.
I also set the IE security level to low, and trun off IE ESC(enhanced security configuration), it doesn't work.
BTW, the IE8 can access the url: myMachineName/_layouts/15/start.aspx#/SitePages/Home.aspx
So I guess I need to add or change some configurations in the website which I created in the sharepoint to fit IE8.
Many Thanks!
I have a Java web application in domain A (that we control). This application displays another website located in domain B (which we do not control) in an iframe. This external website was recently updated to require users to log on before they can see content. They provided us with a URL that will automatically log our users into their site. This URL works when we navigate directly to it in Internet Explorer (we get automatically logged in etc).
However, apparently there was an update to Internet Explorer so that cross domain communication is not allowed. So now when the login URL is displayed in the iframe, it does not successfully log on (I am guessing its being blocked from creating security cookies).
Also, if we browse to the URL directly and get the security in place, then any iframe elements of the site will not work (I am guessing it is being blocked from accessing security cookies).
Does anyone know of a work around for this? Changing the security level on Internet Explorer is not an option (it is controlled by our company's system administrator). Internet Explorer is also our company standard, so we cannot change that (even though it works fine in Firefox).
When you say "elements of the site will not work" what precisely does that mean?
"Cross-domain" interactions have always been restricted in all browsers. This is called "same-origin-policy" and it's the foundation of web security. The "update" to Internet Explorer you're referring to restricts IE such that a webpage on Domain A can no longer navigate a subframe that is inside a page from Domain B. That restriction has been present in IE for 7+ years and is in all browsers. This restriction is not causing your problem.
This most likely problem here is that the subframe fails to set a P3P header that would permit its cookies to be stored. There are perhaps 30 duplicates on that issue on StackOverflow.
To determine if this is what you're encountering, try this:
In IE, click Tools > Internet Options > Privacy tab.
Set the slider to Accept all
Clear your cookies
Restart the browser and retry the scenario.
If this change solves the problem, then the fix is easy: configure the page which is being framed to specify its cookie policy using a P3P response header.
If this doesn't solve the problem, please update the question with more information that would allow others to reproduce it (e.g. traffic logs, live site URL, etc).
It turns out that this was causes by the login site not being on the trusted sites list. Having security add it as a trusted site and pushing that to all company computers solved the issue.
I think this should be releated to IIS settings but don't know exactly what it is.
As you can see below, this login message pops up for each images, 8 images 8 times in Opera.
And the major browsers react to this page different.
IE9 works good(this is the reason why I found this problem now. It's internal site and almost every users use IE...)
Chrome(17.0.963.56 m) works good.
Safari(5.1.2) is also good.
Opera 11.61 has a problem like I said...
And FF SHOWS NO IMAGES and don't even ask for login. And Firebug says it's "NetworkError: 404 Not Found!".
I don't know what's going on.
This site requires to login and it's internal, so I can't give you the link. Sorry for the inconvenient.
And this site is running on Windows Server 2003. And the image containing folder is shared for web(I don't know why it's shared. But don't want to change the setting). I don't know this may cause this situation.
If Opera opens a user name/password dialog, the site is probably sending a WWW-Authenticate header in response to those image requests. You can open Opera's developer tools ("Tools > Advanced > Opera Dragonfly" or right-click in page and select "Inspect element") and use the network feature to inspect the full headers.
I don't know how you can disable this header if it is sent, it depends on the server settings and what type of server you're running, and I'm not at all familiar with Windows Server 2003.
A cheeseburger to the first person who can help me make sense of this. I have a page in a Sharepoint app that uses Telerik's RadUpload to upload files. This has worked for months; last week it stopped working (in Internet Explorer, this detail is important). After talking with a co-worker about the problem, I tried the upload with Firefox; it worked. Not only that, all subsequent uploads from Internet Explorer started working. Flash forward an hour, and the aforementioned coworker, on another Sharepoint site, running on different servers, was having problems downloading (using Internet Explorer). Being half serious, half smart-aleck, I said 'try it in Firefox'. Not only did that work, ALL SUBSEQUENT DOWNLOADS IN INTERNET EXPLORER WORKED! And he re-produced this behavior on another machine. My fear is that this a browser issue. All advice will be greatly appreciated.
a
IE will try and present credentials to a server it knows to be in its Local Intranet zone when it tries to connect (depending on the setting of "Automatic logon only in Intranet zone").
Firefox will only present credentials when prompted, and will generally ask you by popping up a box (unless you've configured a list of sites for it to always present NTLM credentials to).
I've seen a similar case with Sharepoint where you can cause IE to work by logging in with Firefox. I theorized it was due to a permission on a remote resource being for "Authenticated Users", and you're causing your user to authenticate by logging in forcefully. We eventually set the "Automatic logon only in Intranet zone" to "Prompt" and it worked. My theory there was that it wasn't detecting the site as being in the Local Intranet zone for some reason. If you're not accessing a domain with no .'s in it, try also setting your Local Intranet site policy to match the full domain of the Sharepoint server, not just *.example.com - I've read that that can help.
Was it as simple as IE not re-downloading miss-cached .js file, maybe, that firefox did download, making IE work after that?
Pretty gnarly to debug.
Our web application uses Windows Integrated Authentication (aka NTLM Auth) for security.
It's working fine for both IE and Firefox users, but Safari users are seeing intermittent problems. Browsing the site will work fine, but every once in a while there will be problems loading elements of a page (e.g. CSS or JS files). Reload and the problem will go away.
If we use a debugging proxy (Fiddler) we can see that there is a lot of extra 401 requests happening with Safari. Every once in a while a request for a resource will get stuck in a 401 request loop, and eventually fail.
I can't see anything that we're doing to cause this, and it would appear that it's a bug in Safari. Has anyone ran across this issue before, and have any suggestions for a resolution?
Thanks,
Darren.
Some web sites http://www.musteat.org/nodes/show/151 indicate this is an issue with negotiated authentication.
You can turn off Negotiate in favor of pure NTLM in IIS via the NTAuthenticationProviders Metabase setting, and the following ADSUTIL command.
cscript adsutil.vbs set w3svc/WebSite/<SiteID>/NTAuthenticationProviders "NTLM"
Change < SiteID > to the appropriate ID, typically 1.