I am trying to figure out that why my sub domain website works fine with Http but not when its https.
Is there SSL certification problem.
You have a bunch of scripts that are linking with http. Browsers won't run these on a secure page. You need to change the links to https:
<script src="http://bloodsuvidha.vampy.in/js/bootstrap.min.js" type="text/javascript"></script>
This is also true with stylesheets:
<link rel="stylesheet" type="text/css" href="http://bloodsuvidha.vampy.in/css/bootstrap.min.css">
The answers given till now are correct but none solved my problem.
The main problem was my application was behind CloudFlare
Laravel detects a Request as secure or insecure by checking a HTTP header i.e.
$_SERVER['REQUEST_SCHEME']
which remains HTTP even the Request is HTTPS due to cloudflare.
CloudFlare sets a different header for the same i.e.
$_SERVER['HTTP_X_FORWARDED_PROTO']
Which must be checked to detect a request is secure or not
Following this article and making some changes to this I successfully managed to generate HTTPS URL without making any changes to previous application code.
Credit Cybersupernova (Stack User )
Related
I am relatively new to Dapps and IPFS. Was trying out fetching an IPFS asset and I am getting 429 for my requests. This is somehow related to my IP, as I am able to successfully fetch from my friend's IP. Somehow my IP has been rate limited I guess.
Is there any way I can get whitelisted for IPFS. Does it get solved if I host my own IPFS node ?
<html>
<head>
<title>429 Too Many Requests</title>
</head>
<body>
<center>
<h1>429 Too Many Requests</h1>
</center>
<hr>
<center>openresty</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
The response headers also doesn't to return anything useful.
access-control-allow-headers →X-Requested-With, Range, Content-Range, X-Chunked-Output, X-Stream-Output
access-control-allow-methods →GET, POST, OPTIONS
access-control-allow-origin →*
access-control-expose-headers →Content-Range, X-Chunked-Output, X-Stream-Output
content-length →568
content-type →text/html
date →Mon, 02 Aug 2021 05:51:56 GMT
server →openresty
strict-transport-security →max-age=31536000; includeSubDomains; preload
x-ipfs-pop →gateway-bank3-sg1
Please help !
If you're hitting a gateway throttle, it sounds like you're doing requests from a centralised location (as you mentioned, mostly from your own IP). If possible, you can decentralise that access out, having the clients the users are using (if a website, that'd be in the web page) access the gateway you're using themselves, where the HTTP requests are coming from their PCs, rather than all coming from the one server.
However you're also correct when you ask:
Does it get solved if I host my own IPFS node ?
Yes it does get solved, as you're actually using IPFS at that point, instead of just a gateway (HTTP). Your node will pull the data from several other nodes, instead of just that one gateway node.
I have a page which has basic authentication on it. Once I've authenticated my requests for the page and it's resources (CSS etc) have the Authentication header
Authorization Basic NOTREALNOTREALNOTREALNOTREALNOTREAL=
At the end of the body I am loading an external script.
<script type="module" src="/main.js"></script>
This request is not being sent with the Authentication header. It is the only thing on the page which isn't. This causes a 401 repsonse with the following header
WWW-Authenticate Basic realm="mydomain.com"
This happens in both chrome and firefox.
Does anyone know why this is the case or how to get it to be sent?
Looks like this is a quirk of <script type="module">, that causes them all to be treated as CORS requests, and thus they don't send Authentication headers by default.
This can be worked around by adding the crossorigin="use-credentials" attribute to your script tag:
<script type="module" src="/main.js" crossorigin="use-credentials"></script>
should work.
I have been trying to get my HTML5 offline cache manifest to work nicely in Safari when accessing the site with HTTPS.
I have the following setup:
index.html:
<!doctype html>
<html lang="en" dir="ltr" manifest="app.appcache">
<head>
<base href="https://www.example.com">
<link rel="stylesheet" href="//some.cdn.com/styles.css" charset="utf-8">
<script src="//some.cdn.com/app.js"></script>
</head>
<body>
</body>
</html>
app.appcache
CACHE MANIFEST
//some.cdn.com/styles.css
//some.cdn.com/app.js
NETWORK:
*
Accessing my site over HTTP works fine! Assets get loaded correctly and cached; I can use my app offline
Accessing my site over HTTPS in Chrome works fine as well
Accessing my site over HTTPS in Safari breaks :-( Assets get loaded normally, but won't cache. Debugging didn't got me any further. No useful information in the logs
According to the specs, referring to another domain in the cache manifest is allowed.
I have also tried using http:// or https:// explicitly in my HTML and manifest instead of the //-notation. Of no avail.
In my search online I've found some comments about cross-domain requests and that it isn't allowed in the cache manifest, but according to the W3C specs this is allowed (and proved by the fact that the browsers I tested it cache all the assets correctly, except for the combination https & safari.
So apparently I missed an important restriction of the appcache.
As mentioned in https://www.w3.org/TR/2011/WD-html5-20110525/offline.html:
If the manifest's is https: or another scheme intended for encrypted data transfer, then all URLs in explicit sections must have the same origin as the manifest itself.
When attempting to view my site over https, I keep getting a "Blocked loading mixed active content" error in my Firefox console. I am getting this error only for my css and js file.
The reason I am so confused is because the reference to the files in the page code itself is https:
<link rel="stylesheet" href="https://www.example.com/style.css">
But in the console, it shows it as http:
Blocked loading mixed active content "http://www.example.com/style.css"[Learn More]
I can do a view source on the page and search for "http://" and there are no results anywhere on the page.
Any ideas?
I think that you can try with relative protocol caller.
<link rel="stylesheet" href="//www.example.com/style.css">
---------^^
if your users visit your web in http, it loads http, and if the user visit under https it loads https.
This is only for testing purposes, but we have a site that runs on https, and I'm trying to test a new stylesheet on an external server that only has http. However, the browser doesn't seem to recognize the css at all, I'm assuming because it's not https. Is there anyway to force my browser to allow this? It would eventually be on https in production, so I just need a work around for myself. Thanks,
Use a protocol-free URL so the client doesn't recognise it as being an insecure item. The client can then add its own protocol to the request:
i.e. instead of
<link rel="stylesheet" href="http://example.com/css/main.css">
use
<link rel="stylesheet" href="//example.com/css/main.css">