I am using JQGrid extensively in my code base. Now that I have added Content Security Policy default-src 'self', none of my grids are loading.
If I change it to default-src 'self' 'unsafe-inline', the grids start loading again.
Is there any mechanism by which I can tweak JQGrid to play nice with CSP without adding the unsafe-inline directive?
Related
CSP level 3 nonce implementation prevents all the inline events. It is possible to override this using script-src-attr directive in Chrome and edge. But script-src-attr directive is not available in Firefox browser. Thus, all the inline events are blocked. How to fix this issue in Firefox without rewriting the inline events.
I found that cobalt can only open Youtube page, and can NOT open URLs without Content-Security-Policy setting in the response data or in the html page(eg <meta http-equiv="Content-Security-Policy" content="object-src 'none'; script-src 'self' 'unsafe-eval' 'unsafe-inline'">), so is there any CSP config to support that URLs without Content-Security-Policy setting can also be opened?
The Content Security Policy spec:
https://www.w3.org/TR/CSP2/
This is an intentional security feature, because Cobalt is aimed at running applications, not general web browsing. It can be disabled with the command line switch --csp_mode=disable, but this is disabled in gold builds.
The CSP itself only applies to the page associated with the policy. Once you navigate to another page, as long as the navigation is allowed by the current page's policy, the policy will be thrown out and replaced with the next page's policy. But there is no way to use CSP to disable the CSP requirement enforcement.
I am working on a new website. While testing some of the functionality I had a number of debug statements and was watching the logs. It seems that Firefox (at least) loads the "next" page in the menu as well as the page I have clicked on. If I have menu items A B C D E and click on B then I see a request for mysite.com/B and then a request for mysite.com/C in the logs, and so on.
Is this some kind of look-ahead performance thing? Is there any way to avoid it (setting an attribute on the link maybe?) The problem is that the second page in my menu is somewhat heavier as it loads a whole lot of data from a web service. I'm happy for people to do that if they want to use the functionality, but would rather not that every visitor to the front page loads it unneccessarily. Is this behvaiour consistent across browser?
Yes, Firefox will prefetch links to improve the perceived performance to the user. You can read more about the functionality in Firefox here https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ
It isn't possible to disable this in the client's browser, however the request should include the header X-moz: prefetch which you can use to determine if it is in fact a prefetch request or not, and potentially return a blank page for prefetch requests. You can then use Cache-control: must-revalidate to make sure the page loads appropriately when actually requested by the user.
If you happen to be using Worpdress for your site, you can disable the tags with the prefetch information by using:
Wordpress 3.0+
//remove auto loading rel=next post link in header
remove_action('wp_head', 'adjacent_posts_rel_link_wp_head');
Older versions:
//remove auto loading rel=next post link in header
remove_action('wp_head', 'adjacent_posts_rel_link');
Yes, it's called prefetch. It can be turned off in the client, see the FAQ:
https://developer.mozilla.org/en-US/docs/Link_prefetching_FAQ
I'm not aware of a way to turn it off via the server
I'm under the impression that the user agent stylesheet in browsers such as Safari, Chrome and Firefox is something that is internal to the browser and can't be directly modified (rather a style property needs to be overridden).
I'm also under the impression due to various websites including Mozilla's that the default value of the box-sizing property for Webkit and Mozilla is "content-box."
I tested this on a rather simple dummy page viewed in various browsers.
My problem is that on two pages in our production application the default property is different, and we can't figure out why this is.
One one page we see a box-sizing property of "border-box" in the Web Inspector or console. It's assigned to the CSS selector input:not([type="image"]), textarea.
On the other page there is no mention of the box-sizing property in the Web Inspector or console.
Does anyone know if there's some way to directly affect the box-sizing definition in the user agent stylesheet for a particular page? Maybe there's a library that does this? We're using prototype.js and swfobject.js in the application...
UPDATE: In case I wasn't clear on almost every page in my web application and in every "dummy" page I've tested on the box-sizing property has the default "content-box" value. For some reason one particular page in my web application shows in the web inspector that the user agent stylesheet (the one used by the browser for its defaults) has set that property to "border-box." I can't for the life of me figure out why this is. I'm looking for anything that might cause Firefox to change what its default value for that property is.
Just had this same issue. What was happening in my case was that someone had put a snippet of Javascript code above the <!doctype html>. As a result, when I inspected DOM through firebug, it appeared that the document didn't have a doctype.
When I removed the snippet of JS code such that the doctype declaration was at the very top of the file, the doctype reappeared and fixed the box-sizing problems I was seeing (the same one you had).
See:
Hope this helps.
I had the same issue on chrome which by default added the following user agent style rule:
input:not([type="image"]), textarea {
box-sizing: border-box;
}
After adding the doctype property <!DOCTYPE html> the rule no longer appeared.
No, you can't touch the browser default stylesheet, and yes, browsers do have different rules for box-sizing specifically in respect to form fields. This is for compatibility with old browsers that used to implement form fields entirely with native OS widgets that CSS couldn't style (and so which didn't have ‘border’ or ‘padding’ as such).
Why not just put your box-sizing/-moz-box-sizing/-webkit-box-sizing rule in the site stylesheet? Works for me, I often use this to make inputs with set widths line up across modern browsers. (IE 6–7 don't support it, though, so need some extra help.)
I'm using jQuery's ajax .get method to retrieve data from my server. Works perfect in Chrome, but in IE9 it is not sending the Cookie header and that breaks the app. Any idea why? Here's the jQuery code:
$.get(this.server + 'rest/photo/' + this.profileId + '/count', function(data) {
$('#imageCount').html(data);
});
I have the same problem here, I can't get the jQuery .ajax() function to work. The only workaround I found is this:
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />
You can add this meta tag to the top of the page to get it working. But it doesn't feel like a good solution. I think the problem is that the xmlhttprequest object in IE9 is different, so jQuery cannot find the respective object, therefore ajax is not triggering.
I ran into a similar issue to the OP many years later with IE9 which, sadly, is still hanging on.
Every browser I tried, including IE10+, seemed fine with passing cookies to my backend, but IE9 would just drop them. It didn't seem to matter what attributes were on the cookies. The main page and API were on the same domains and the cookies matched, the schemes were the same. I wasn't doing anything with IFRAMES, so the P3P 'potato' hack didn't help.
So I started doing some research on what it was about IE9 that could be different. This Microsoft post was very enlightening, and outlines all the things the IE8 and IE9 did to help lock down CORS security holes:
Must use HTTP(S), and both endpoints must use the same scheme
Must use GET/POST
No custom headers allowed
Only text/plain content-type allowed
More sensitive to Security Zone settings
Cookies will be stripped from the request
That last item about the cookies got me thinking, what if IE9 thought I was making a cross-site request? It certainly looked like it was getting shot down in fine fashion like that. I had already checked some of the obvious things like the scheme and domain, but maybe I didn't check everything.
The solution? Specifically, I was using reqwest as my ajax library. It has a cross-origin parameter, which I had left set to true for some reason. Setting it (correctly) to false did the trick - all my cookies were picked up by the server. So it was a dumb mistake, but I learned a thing or two.
Hope this helps someone!