I have a web application that uses ajax with prototype.js (Ajax.Updater).
new Ajax.Updater('someID','/some/url',
{
asynchronous:true,
evalScripts:true,
parameters:Form.serialize(Event.element(event).form),
requestHeaders:['X-Update', 'someID']
}
);
Some (not all) IE9 users experience a strange phenomenon.
UserAgent of normal (non-ajax) HTTP requests indicates that the browser is IE9, not in Compatibility View.
UserAgent of ajax HTTP requests indicates that the browser is IE7 (IE9's Compatibility View).
I want to force the browser not to use Compatibility View in ajax HTTP requests, but the html already has a meta tag : <meta http-equiv="X-UA-Compatible" content="IE=edge">.
Does anyone know the reason or workaround?
This is a possible solution - but not fully researched - try setting
Header set X-UA-Compatible "IE=edge"
in your httpd.conf or .htaccess file - this will add the X-UA-Compatible header to all responses from Apache to force IE not to use Compatibility Mode
Related
I am using the following Content Security Policy in Report-Only mode:
Content-Security-Policy-Report-Only "default-src 'self'; report-uri /log_violations"
When I go to a URL on the server with an HTML page containing the following:
<!DOCTYPE html>
<head>
<title>
Test document
</title>
</head>
<html>
<body>
Hello
</body>
</html>
I am seeing the following error message in Firefox 57.0 on line 1:
Content Security Policy: The page’s settings observed the loading of a
resource at self (“default-src http://www3.thestar.com”). A CSP report
is being sent. Source: ;!function(){var t=0,e=function(t,e){ret...
In other browsers, like Edge, Chrome, I haven't seen these errors.
Any thoughts on whether this is a Firefox quirk or something I've set up incorrectly? I'm stumped as to why the policy is rejecting line 1 of every page.
You probably have an extension installed and enabled that is injecting content into the page. Try opening the page in a new Firefox profile without any extensions to see if you see the CSP violation reported.
Firefox is planning to exclude content injected by extensions in CSP checks starting Firefox 58 so this should reduce the noise from extensions doing stuff on a page.
From the Mozilla blog,
Starting with Firefox 58, the CSP of a web page does not apply to
content inserted by an extension. This allows, for example, the
extension to load its own resources into a page.
We're getting allot of Mixed Content errors on the cart page of our Magento Store
Mixed Content: The page at 'https://www.magento.com/onestepcheckout/index/' was loaded over HTTPS, but requested an insecure stylesheet 'http://fonts.googleapis.com/css?family=Lato:400,300,700,900'. This request has been blocked; the content must be served over HTTPS.
I can see the google font file is being called in the head section of our theme via http
<link href='http://fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
I'm wondering what is the best way to solve this issue should I change the line above to:
Option 1
<link href='https://fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
OR
Option 2
<link href='//fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
Which is the best method considering most of our site uses http? I was not aware of Option 2, it seems like a very good approach.
I found a good answer here.
The second option, protocol relative links seems to be the best option.
UPDATED ANSWER
To give a more complete answer, protocol relative URLs help to avoid Mixed Content errors by requesting the resource from whatever protocol the browser is viewing that current page through. This is really useful when your site has pages that use both http & https, as in my case checkout page was being loaded over https while the rest our site uses http.
Example
So if we use a protocol relative url to link to a resource.
<link href='//fonts.googleapis.com/css?family=PT+Sans' rel='stylesheet' type='text/css'>
When we're on https://www.magento.com/onestepcheckout/index/ the resource will be loaded via https, https://fonts.googleapis.com/css?family=Lato.
And if we're on http://www.magento.com/ the resource will be loaded via http http://fonts.googleapis.com/css?family=Lato
This will avoid any Mixed Content Errors.
Caveats
There are a few things to consider when using this approach though.
IE6 does not know how to hanler protocol relative urls. IE6 has less than 1.7% of the browser market.
IE7 & IE8 support protocol relative URLs but they’ll end up fetching the
resource twice. Once from HTTP and once over HTTPS, which will slow
things down. Again, these older browsers account for very little of the browser market.
Does not work in all email clients (e.g Outlook), so avoid using protocol relative urls in HTML emails
You have to be sure that the server you’re requesting from is capable of serving content over both HTTP and HTTPS. If not you might end up fetching content from an unsecured or nonexistent server port.
Further Reading
https://developer.mozilla.org/en-US/docs/Security/MixedContent/How_to_fix_website_with_mixed_content
http://www.paulirish.com/2010/the-protocol-relative-url/
http://billpatrianakos.me/blog/2013/04/18/protocol-relative-urls/
I got the exact same error while adding products to cart, I was deploying CDN for Magento 1.9 let me share my solution,
Accoriding to Chrome Console, the URL returned by js about ajaxcart started with HTTP , so I go to review the parameter construture I found this :
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var myajaxcart = baseUrlAjax + 'ajaxcart/index/index/id/';
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var urladdajaxcart = baseUrlAjax + 'ajaxcart/index/index/';
js/cmsmart/jquery/ajaxcart/cmsmart-ajaxcart.js: var checkouturl = baseUrlAjax + 'checkout/cart/add/';
and baseUrlAjax is controlled by PHP echo $url
app/design/frontend/default/theme691/template/cmsmart/ajaxcart/page/head.phtml: var baseUrlAjax = '<?php echo $url; ?>';
and $url is controlled by
app/design/frontend/default/theme691/template/cmsmart/ajaxcart/page/head.phtml >>>
#$url = Mage::getBaseUrl(); #oldone
$url = Mage::getUrl('',array('_secure'=>true)); # set to this new one
Bingo!
Reffered to this page : How Do You Get The Store Secure URL in Magento?
In Chrome I get the following error messages in the console
[blocked] The page at https://domain.com/home.html ran insecure
content from
http://domain.com/typo3temp/stylesheet_09c1ef800c.css?1345207892.
if I call https://domain.com. The user gets a page without stylesheets and images. What can I do against this?
The files are included like <script type="text/javascript" src="js/lib/jquery-1.5.1.min.js"></script> but I don't want to define the domain.
Should I completely switch to https by setting the base URL with https? Which other possibilites do I have?
I used
config {
baseURL = https://domain.com
}
and adapted all links which had a http in the beginning (otherwise the slider stopped working because Chrome didn't load the other ressources ...). Seems to work now.
I'm prompting users of IE to install the Chrome Frame add-on. If the user is on IE and doesn't have Chrome Frame installed, they are redirected (server side) to a page with a custom message and the install page in an IFrame:
http://www.google.com/chromeframe/?quickenable=true
After install has completed, Chrome Frame is not loaded in the current tab. Is there a way to force it to be? I've tried including redirect=True but that doesn't work because I have the page in a frame.
You make your pages work with Google Chrome Frame by adding a single tag, like this:
<meta http-equiv="X-UA-Compatible" content="chrome=1">
or by adding an X-UA-Compatible HTTP response header:
X-UA-Compatible: chrome=1
Add the meta tag to the html file which you are loading in the frame and it should initialize the chromeframe.
I find this kind of odd I haven't been able to find any information on someone with a similar issue. Anyway, I've integrated Spring Security with GWT, and it appears to work correctly...for the most part. I'm having a caching issue with the main html page in IE and Chrome.
I've separated out Spring Security login to a login.jsp that redirects to my Application.html page (the GWT page), and when I first start the app and access the page, it appears to be working fine in all browsers. I get directed to the login page, because I'm not authenticated.
The issue is that in Chrome or IE, if i close the browser after a successful login, and directly browse back to that Application.html URL, it still renders as if I'm authenticated. I look in my console, and the log statements for spring security verify I am not authenticated. The moment i hit f5 to refresh the page, I get directed back to the login.jsp url.
I'm lead to believe this is some caching issue because when I close the browser and reopen to the html page, even though it renders like I'm logged in, the console log statements say I'm not, and if I run in debug mode, the OnModuleLoad() in Application.java never gets hit.
Finally, this appears to work properly in firefox...If anyone has seen this issue or has any advice of where I need to look to fix, I would greatly appreciate the assistance.
I've encountered a similar problems with a web app that I've been working on. I attempted to prevent the browser from caching the page by adding these tags to the page:
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">
Unfortunately, this wasn't enough to prevent caching for all browsers. I finally ended up converting the page to a JSP page and adding these statements to the top:
<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setDateHeader("Expires", 0);
%>
I haven't been able to reproduce the problem in Firefox, Chrome or Safari since I made the change. I haven't tested the page with Internet Explorer yet.