Exclusion of the URL scheme in front of a URL - javascript

Recently I've seen these kinds of URLs in CDN documents:
//cloudflare.cdnjs.com/foo
And I realised that they lacked the http: or https: in front of them.
Hmm, I thought, and tried implementing them in a local test, and realised that they didn't work (they resolved // to be file://, though it was supposed to be http:).
Then when I uploaded this to my testing server, it worked (resolved // to be http://).
So I was wondering, why would anybody write it without the protocol?
Thanks.

(Technically, it's not the "protocol", but the URI scheme)
For HTTP, excluding the scheme means that the UA will use the current scheme (and therefore protocol) to retrieve the file, which means some copy + pasted code can be re-used for both HTTP and HTTPS (or even SPDY) requests without triggering the "Partially secure page" warnings in browsers.

Depending on the user's security settings, browsers will often present a warning if a page serves up mixed content (both HTTP and HTTPS). Of course, you could just code your HTML using the same protocol that you intend the page to be hosted with. However, it's not uncommon to use the same HTML in both secure and non-secure portals. Furthermore, you'd really prefer your HTML to be agnostic to the underlying protocol.
Writing CDN links like this makes sure that the CDN request uses the same protocol as the host page.

Related

Mixed Content: Rewrite Javascript to use HTTPS-only

I'm using loads of javascript on my Website and my Website throws out Mixed Content Warnings (about 30 of them, telling me, I am using "Scripts of unsafe sources") and as I'm not into javascript that much, I wanted to ask if (and if yes, if you know it) there is away to add a script to rewrite my javascript http requests.
If possible, you should remove all http and https references from your links. That means that this link:
https://www.google.com/
should be rewritten as:
//www.google.com/
If you do that, the browser will automatically add http or https, depending on which protocol your webpage is currently using. Doing this will allow you to move over to HTTPS whenever you'd like with minimal impact.
Note that some websites still don't support HTTPS, so in those cases you'll have to use HTTP. However, you really should never request any HTTP resources if you are on HTTPS because browsers will display your site as insecure to users.

Loading script from HTTP is automatically converted to HTTPS for some users

I am trying to load socket.io using the following code:
<script src="http://cdn.socket.io/socket.io-1.4.5.js"></script>
However some users have reported the following error to me:
Failed to load https://cdn.socket.io/socket.io-1.4.5.js ERR_SSL_PROTOCOL_ERROR
Is this an automatic security setting on modern browsers? And if so can it be disabled?
The problem is not your fault!
Accessing that link in my browser fails as well, and inspecting the unsuccessful request shows that the following header was set:
Upgrade-Insecure-Requests: 1
This tells the browser to "upgrade" all http:// URLs to https://, which seems to mirror the error your users are reporting.
ERR_SSL_PROTOCOL_ERROR indicates that the SSL certificate for https://cdn.socket.io/ is incorrectly configured and thus the browser (rightly) assumes the worst, and chooses not to trust data served from that domain over the secure protocol. When the domain is configured to "upgrade" insecure requests to secure ones, and secure requests are rejected by the browser, it becomes clear why there is no way to access the content correctly at either URL.
I would contact the administrators of the website and inform them of the problem, or just simply switch to another CDN like Chris Chen suggested:
<script src="https://cdnjs.cloudflare.com/ajax/libs/socket.io/1.4.5/socket.io.min.js"></‌​script>
Sounds like the users who are experiencing that error are hitting the https version of your page. Best way to deal with this issue is by changing your code to:
<script src="//cdn.socket.io/socket.io-1.4.5.js"></script>
Or
<script src="https://cdn.socket.io/socket.io-1.4.5.js"></script>
The former is preferable (because it is faster for http users) unless you are working with an .html or .htm page and want to open it without a web server.
The link is not working at all from anywhere. Is it a private link that require certification?
If you just want socket.io.js, use link from https://cdnjs.com/libraries/socket.io

Difference between Localhost and opening html file

What is the fundamental difference running a file using a server in localhost, and opening a file such as file:///Users/$user_name/$your_directory/index.html, assuming no backend is used, and it is only frontend and contains html/css/js
How does this also affect interactions with other server ie. ajax requests?
I am sorry if this is too broad, but I haven't found a solid answer to these underlying questions.
Fundamentally, assuming at some point you're going to host the result on an actual web server, the former matches the target environment while the latter doesn't. Browsers treat local files and files served from web servers (even localhost web servers) differently, although very similarly. One aspect of this is the encoding: When you retrieve a file from a web server, the process of determine what encoding the data is in is different from opening a local file.
How does this also affect interactions with other server ie. ajax requests?
This is one of the primary ways in which they're handled differently, and it even varies from browser to browser. A page loaded from a file:// URL has origin null from a Same Origin Policy standpoint. Some browsers (like Chrome) disallow Cross-Origin Resource Sharing entirely for origin null, even when the server you're trying to talk to has a wide-open CORS policy (*). Others (like Firefox) allow origin null to match the wildcard.
In general, for best results, ensure that your development environment matches your deployment environment in the important ways. That means doing your development using a web server process rather than local files. Most IDEs will happily provide that process for you; if not, Apache or Nginx aren't hard to install.
answer is simple,
if u don't have made active backend yet for "index.html" then it would not effect.e.g.-"localhost" and "index.html" will be same this time.
but when u start working with the backend,then most of the backend processes need an active server (need localhost).
e.g.-
1.
fetch('local.json')... //fetch json or any file would not work for local files.
2.
u may not ineract with mysql/django etc. databases.
means it cause errors in signup/login , store any image/video/docs at database etc.
so better is work in localhost, it's most easy way is :-
VScode(IDE) >> extenctions >> live server (just need to click a button to make
localhost and click again to stop localhost)
https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer
It won't make any difference, I think.
But there is an exception when using Chrome! Sometimes I have seen if a html file is added with some CDN link, then it doesn't loaded into html specifically in Chrome but if you try the same file in Firefox or Internet Explorer, it works.
I have faced this problem and hence I always put it under local IIS default website.

http to https - Make browser request corresponding https URLs for http URLs, without needing to edit all pages and manually change all URLs to https?

I am interested in switching my entire site from http over to https.
My concern is that I have some content that uses absolute http URLs.
I will need to edit each page in order to change those URLs to relative but that might take me a while to accomplish.
What I would like to know is if there is a way to use Javascript via the Google Tag Manager in order to re-write local absolute URLs to be HTTPS and not HTTP?
If this is possible, could it be used as a permanent solution?
One solution to consider is the Content Security Policy upgrade-insecure-requests directive.
The upgrade-insecure-requests directive instructs user agents to
treat all of a site's unsecure URL's (those served over HTTP) as
though they have been replaced with secure URL's (those served over
HTTPS). This directive is intended for web sites with large numbers of
unsecure legacy URL's that need to be rewritten.
It’d amount to configuring your Web server so all pages on your site get served with this header:
Content-Security-Policy: upgrade-insecure-requests
So the effect of adding that header would be: for any page at your site served with an https URL, any time a browser sees in one of those pages an http URL for an embedded (sub)resource —whether it be a URL for a stylesheet, script, image, video, or whatever—the browser will automatically (transparently) try to fetch the resource from the corresponding https URL instead.
For more details, you can see the Upgrade Insecure Requests spec.
2018-05-11 update
The upgrade-insecure-requests directive is now supported in all major browser engines (including Edge 17+ and Safari 10.3+):
https://caniuse.com/#feat=upgradeinsecurerequests
The downside of using it now is, so far it’s only supported in Firefox (since Firefox 42) and Chrome. But it also:
has an open Safari/WebKit implementation-tracking/feature bug
is under consideration by Microsoft for implementation in Edge
P.S., I work at the W3C, where we recently (finally) enabled TLS/https access to all W3C site resources—and since the W3C has hundreds of thousands (maybe millions) of pages with http URLs for embedded subresources, the way we were able to make it happen was in part by serving the Content-Security-Policy: upgrade-insecure-requests header across the entire site.
The article Supporting HTTPS and HSTS on w3.org gives more info about the deployment details.
By the time the JavaScript is executed, the problematic resources may already be loading over even loaded.
You can simply search through your code for any instances of http:// and replace those with // or relative URLs.
If your content is more complex (say, distributed over multiple machines), you can use a mirroring script (like wget --mirror http://example.net/) to download a static version of your entire page, and search that.
Then, set up HTTPS (first for you only, then for all your testers) and check that everything works fine. Once you are sure that is the case, allow everyone to come over HTTPS. Finally, a bit later, consider redirecting HTTP to HTTPS and implementing secure cookies, HSTS and HPKP.

Disable internet explorer error

I am getting below error in IE8
"Do you want to view the webpage content that was delivered securely"
To disable this error we need to set this option
"Internet options -> Security -> Internet -> Custom -> Miscellaneous -> Display Mixed contents"
to enable
I am looking for a solution that can be done in code (probably javascript). Please tell me guys if have face any of such problem. The reason I am looking for a programmatic solution is because I cannot expect every user to enable this option.
You need to change your website to not embed any http:// resources on a https:// website. There is no other solution (except maybe not using HTTPS at all).
Actually, it would be very bad if scripts on a website could disable this warning. Mixed content can easily compromise the whole security provided by HTTPs e.g. when a script is loaded via http - it could be easily replaced e.g. through a MITM attack or DNS manipulation and then do anything with the website itself that was loaded securely.
You can't disable this security policy using javascript.
As #ThiefMaster said, this error is produced because you have a combination of things being fetched by both http:// and https://.
If all resources that you are currently serving via http:// can successfully be served via https:// instead, then you should change them all to do so.
Once they are all consistent, the error should go away.
A better way of referencing your URLs might be to use "protocol relative URLs" instead. This means that instead of "http://myserver.com/dir/resource.js" you use "//myserver.com/dir/resource.js" (i.e. remove the "http:" or "https:"). If you change all your URLs to that format (which is perfectly valid), then if the page itself is served over HTTP, then all resources (javascript, CSS, images, etc) will be served via HTTP as well. Likewise, if the page is served via HTTPS, then all resources will be served likewise. Again, make sure you can serve all resources this way first.

Categories

Resources