Develop Reference

Add a HTTP link to SSL HTTPS page without causing Mixed-Content "Not Secure" error

How can I add un-secured HTTP links on this page without causing the error "Not Secure."?
I have a secured web page with SSL HTTPS.
This web page is a dashboard with 100+ buttons which all contain links of external websites.
Unfortunately, not all of these websites support HTTPS ...common its 2020!
Is there any way to resolve this issue while maintaining the site lock?
Attempt #1
<link rel="ampHtml" href="http://example.com/">
Attempt #2
I used TinyURL to convert my HTTP links into short URLs which have
HTTPS. ...this works for most of the links (which is great!)
The remaining links when clicked have additional Javascript which is
adding URL querystrings to the end of the URLs. These strings apply on
the TinyURL successfully, but does not on the final destination URL.
The only other solutions I can think of (if even possible) is ...
JavaScript to convert specific links onClick to HTTP before opening a new tab and loading the website.
JavaScript to delay the load of the HTTP link.

You can make a redirect page. The most basic way is making a redirection page with JavaScript.
if (window.location.search.includes("?url=")) {
var url = window.location.search.replace("?url=", "");
window.location.replace(url);
}
Basically, what's happening is that it redirects from a secure page to a non-secure page without causing a 'Mixed Content' error. It gets the url parameter from window.location.search and then it redirects to that.

Mixed content jQuery ajax HTTPS request has been blocked on Laravel

I think this question will be easy for someone and will be a face-palm situation for me.
I have a Laravel 5.3 site, and various pages have ajax requests. Because I use the csrf_field() feature, they work fine.
But there is one page where the ajax produces this error:
Mixed Content: The page at 'https://example.com/fb/reports' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://example.com/fb/json?levelType=&id=&aggLevel=ad&start=&end='. This request has been blocked; the content must be served over HTTPS.
My javascript looks like this:
var relUrl = '/fb/json/';
var payload = {
levelType: levelType,
id: id,
aggLevel: aggLevel,
start: start,
end: end
};
console.log(relUrl);
return $.ajax({
type: 'GET',
dataType: 'json',
data: payload,
url: relUrl,
headers: {
'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
}
});
I've read tons of articles about this error. I've tried tons of suggested solutions, including changing the relative URL to the full https URL, or starting it with 2 slashes.
I've even tried changing the way my Laravel routes work and am now using just querystring parameters.
I've studied all of the articles below (and more).
Also, since this one ajax query is in a password-protect part of the site (and the ajax queries that work are in a public/open part of the site), I figured maybe that was related to the problem. But then I used SSH to log into the production server and vim to temporarily remove the line that required any authentication, and the https error still happens.
What steps can I take to debug further from here? What logs can I 'tail' on my Cloudways server?
Is there anything that Cloudflare might be interfering with (which I doubt, since other ajax queries work, all on https)?
Thanks!
jQuery AJAX Request to HTTPS getting served to HTTP with Laravel and Select2
This request has been blocked; the content must be served over HTTPS
Mixed content issue - insecure XMLHttpRequest endpoint
XHR response blocked by Chrome, because of mixed content issue (http/https)
Forcing AJAX call to be HTTPS from HTTPS Page
MixedContent when I'm loading https page through ajax, but browser still thinks it's http
jQuery ajax won't make HTTPS requests
Laravel 5.1 ajax url parameter is url

Summary:
I needed to replace var relUrl = '/fb/json/'; with var relUrl = '/fb/json'; (remove the trailing slash) because that's what my Laravel web.php routes file expected.
In Chrome console, I noticed that the https XHR request was being "canceled" and replaced with an http request.
So then I used ssh to log into the remote production server and vim to temporarily disable the requirement of authentication.
Then in the Chrome console, I defined and ran a new ajax command using an absolute https URL with querystring params on the end. That worked (no mixed content error). Then I tried a relative URL like that, and it worked too.
Even a relative URL with no payload or querystring params or trailing slash worked.
Then I added the trailing slash again, and it didn't work.
I still wish there had been an easier way to trace or debug the redirect paths or whatever was happening. I still feel like I stumbled onto the answer clumsily (after many hours) instead of knowing how to dissect this problem reliably.

When changing from HTTP to HTTPS, it's possible to get the problem Mixed content issue - Content must be served as HTTPS.
So, first, modify APP_URL in the .env file, if we use the assets helper, this shouldn't give any problem with the URL.
APP_URL=https://url.net
Finally, add the following to the beginning of **api.php** or **web.php**:
if (App::environment('production')) {
URL::forceScheme('https');
}

Chrome extension Background and content script posting message

I have a content script which includes jquery ui component and i want to send data to my server with http post. However i have come to realize that you can not send http post message to a https website or vice versa. If i send my message to the background script and post from there will i have a problem about it? Will it make a difference if the site is http or https? If it makes a difference how can i get this done?

Yes, you can use http POST, as well as any other http method (e.g., GET, PUT, PATCH), in a content script -- as well as a background script, for that matter.
However, in both cases, the URL to which you're sending your request must be declared in your extension's permissions. You do this in the manifest. For example, if you would like to send http requests to http://www.some-domain.com, you must add that URL (or a pattern matching that URL) to the permissions array of your manifest:
{
...
"permissions": [
"http://www.some-domain.com/*"
],
"name": "Test",
"manifest_version": 2,
"version": "0.0.0"
}
You can add wild cards to your URL permission patterns; thus, if you'd like to match both https and http, you can do something like *://www.some-domain.com/*. See the official literature here.
I should warn you that if you are attaching a content script to a page that was loaded as https rather than http, you will likely not be allowed to send an unsecure http request due to Chrome blocking mixed content, which I believe requires a user override. So a good rule of thumb is: if you're attaching your content script to a page loaded via http, then use http to send the request; if you're attaching to a page loaded via https, then use https.
One last tip: Don't forget to reload your extension after you've changed the manifest, or the permission changes won't be reflected. To reload your extension, go to chrome://extensions, find your extension, then hit reload.

If you send from your background script there is no problem with switching protocols but you had to declare permission to these urls:
see more at the google manifest documentation and this duplicated question

Why does the CDN's have 2 // instead of http or https in front of the URL

I don't understand that why I look at the following website for a CDN, the URL's start with a double "//". I have seen this on JQuery and Bootstrap. Is it up to the person to put http:// or https://?
http://www.bootstrapcdn.com/
<link href="//netdna.bootstrapcdn.com/twitter-bootstrap/2.3.2/css/bootstrap-combined.min.css" rel="stylesheet">

That is a protocol relative URL:
If the browser is viewing that current page in through HTTPS, then it’ll request that asset with the HTTPS protocol, otherwise it’ll typically* request it with HTTP. This prevents that awful “This Page Contains Both Secure and Non-Secure Items” error message in IE, keeping all your asset requests within the same protocol.

It's just like omitting the domain: href="/folder/file.html" where the browsers just assumes the current domain.
In your case the browser will assume the current protocol.
Absolute URLs omitting the protocol (scheme) in order to preserve the one of the current page

How do I get the URL path after a redirect -- with Javascript?

This could be a little off the ballpark, but a friend asked me about it and it's kind of bothering me. How do you figure out the current path in your address bar if the server redirects all requests to a default file, say, index.html.
Let's say you entered:
www.example.com/
And your server configuration automatically redirects this request to
www.example.com/index.html
But the address in your url bar does not change! So how do you figure out using Javascript that the path on this url is index.html?
I looked into location.pathname but that's only giving me /.
Any ideas?

The problem is that it's not actually a redirect. When you type 'www.example.com' into your web browser, the browser generates an HTTP request like the following:
GET / HTTP/1.1
User-Agent: curl/7.16.3 (i686-pc-cygwin) libcurl/7.16.3 OpenSSL/
0.9.8h zlib/1.2.3 libssh2/0.15-CVS
Host: www.example.com
Accept: */*
Note that it's requesting a document named literally /. There are two possible responses by the server:
HTTP/1.1 200 OK
(more headers)
Content...
And
HTTP/1.1 301 Moved Permanently
Location: (location of redirect)
(more headers)
(Optional content)
In Case #2, you can get the redirect location since it's actually a redirect. But in Case #1, the server is doing the redirection: it sees a request for / and instead serves up the content for whatever its index page is (e.g. index.html, index.php, default.aspx, etc.). As far as your browser is concerned, that's just the content for the document /. It doesn't know it's been redirected.

If the redirect happens on the server then the browser is not aware of it and you cannot access the actual resource in javascript. For example, a servlet might "forward" to another resource on the server.
If the server sends a redirect command to the browser and the browser requests the new url then the browser does know about it and you can get it.

There is no way to do this, except somehow embedding the webserver's filename into the document. As far as the browser is concerned, there is no index.html, the page is just /.