I have the following code in my Fastify server hosted on Heroku:
this.server.addHook('preHandler', async(req, reply) => {
const isHttps = req.headers['x-forwarded-proto'] === 'https';
if (isHttps) {
return;
}
const {
method,
url
} = req;
if (method && ['GET', 'HEAD'].includes(method)) {
const host = req.headers.host || req.hostname;
reply.redirect(301, `https://${host}${url}`);
}
});
The idea is to prevent access to the server through HTTP and force redirection to HTTPS at the application-level, since it is not possible otherwise on Heroku.
My question is: if the first request to the server via HTTP (before the redirection happens) contains sensitive information such as a username/password, wouldn't that still be "dangerous" or compromising somehow?
You have probably mis-configured something on Heroku.
Heroku domains (.herokuapp.com) are by default HTTPS enabled. The same page has a guide for custom domain SSL setup guide. Since you are talking about (username + password), I am going to assume this is a website. All you need to do is setup CORS with fastify-cors. Your website should ALWAYS be served over HTTPS.
Also you should not use the logic above. Fastify isn't meant to be used as a proxy server. The docs strongly suggest using a front-facing proxy server like nginx. With Heroku you don't need all these. It already handles this for you.
In the future you could also use Cloudflare as a "proxy server" outside Heroku.
Related
I'm having a CORS related issue with google cloud run on a service that
requires authentication.
If I try to execute a curl command through the cli, with a Bearer token,
everything works fine.
Unfortunately if I try to execute the same call through ajax in javascript,
I receive a 403.
const http = new XMLHttpRequest();
const url = 'https://my-app.run.app';
http.open("GET", url);
http.withCredentials = true;
http.setRequestHeader("authorization", 'Bearer ' + id_token);
http.send();
http.onreadystatechange = (e) => {
console.log(http.responseText)
}
The error in the cloud run logs is this :
The request was not authenticated. Either allow unauthenticated invocations or set the proper Authorization header. Read more at https://cloud.google.com/run/docs/securing/authenticating
The container is never hit.
The issue I'm seeing is that, as I'm making the call using ajax, in a web
browser. The web browser is making a pre flight request ( OPTIONS on the
url ) without sending the Authorization header ( which is an expected
behavior )
The problem seems to be that cloud run tries to authenticate the OPTIONS
request and never makes it to my container, which, as far as I understand,
shouldn't be done. (
https://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 )
Is that a known issue with cloud run ?
How could I make an ajax request to an authenticated cloud run service ?
(Cloud Run PM)
This is a known issue. There are a few options:
Allow unauthenticated requests and do CORS/auth yourself
There is a variation of this that uses Cloud Endpoints running on Cloud Run in front of your compute. Have Endpoints do your end-user auth, then forward the request to your backend.
Serve from the same domain (e.g. use the Firebase Hosting proxy)
We've considered implementing Istio CORSPolicy, which would return CORS headers before the auth check, though we're not committed to this as of now.
I have a problem when I want to create an authentication system using VueJs as the frontend (http://localhost:8080/#/login) and Laravel 5.6 as the backend. When I try to submit login form using the api login url http://127.0.0.1:8000/api/v1/login, I get the error message:
Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at http://127.0.0.1:8000/api/v1/login.
(Reason: CORS request did not succeed).
I don't know how to solve this problem.
Could anyone here help me to solve my problem?
NOTE : I have to install laravel-cors before
This is an old question, but I'll reply nonetheless.
For me this error was caused by a self-signed certificate. If you open developer tools, select the network tab, click the call that failed CORS you can see the security tab. Click it to open it. If a cert is giving you problems the text "An error occurred: SEC_ERROR_INADEQUATE_KEY_USAGE" should be visible.
To resolve this just go to the URL that gave you the CORS error, and accept the cert manually.
Cross Origin Resource Sharing is a mechanism that uses additional HTTP headers to tell a browser to allow the web application running on one origin (client) have permission to access selected resources from a server at a different origin.
Basically, your Vue app (http://localhost:8080) needs to be allowed access to your Laravel endpoint (http://127.0.0.1:8000/api/v1/login) This is to prevent me from hitting your Laravel endpoint from my malicious website and acting like an authenticated user.
Based on the docs, you need to add 'allowedOrigins' => ['*'], but that means you're opening up your backend to all requests. That's fine if it's a public API but in this context it doesn't sound like you want that. Instead, in this case it would be 'allowedOrigins' => ['localhost:8080'], so that your Vue app can consume your Laravel server.
You have to use either localhost or 127.0.0.1 for all the requests. In general in your code you should make calls to the server by just appending the URI to the current host, without re-adding the host and port in the URI string. If you load your page from a given host, for example 127.0.0.1 and then try to make an AJAX request to another host, for example www.host.com, the request gets blocked to prevent XSS attacks
It sounds like you are running this in dev mode via webpack currently? If that is correct and your workflow is that you are going to build the Vue application and have it co-reside with your Laravel backend then you just need to update config/index.js to have a proxyTable entry that forwards webpack requests to the correct dev Laravel backend server.
This would look something like this.
module.exports = {
dev: {
proxyTable: {
"/": "http://127.0.0.1:8000/api/v1/login"
}
}
}
There is additional information available on how this works; https://vuejs-templates.github.io/webpack/proxy.html
I was stuck with this error recently while I was trying to get one of our old websites hosted via Azure (App Services) up and running again.
Reason: CORS request did not succeed was the error showing in the browser console, however, it turned that for our case the URL mentioned in the CORS error doesn't exist anymore - its referring to the old https://******.azurewebsites.net service url we had (previous hosted in Azure - App Services).
So also check that the URL mentioned in the CORS-error is in fact working.
In my case the computer was not displaying the correct date and time. When I try to view the page I would get the "CORS request did not succeed." Once I updated to the correct time and date the page displayed normally.
I had to change the base URL of axios. I didn't notice it was https://, not http://
file: src\store\index.js
change the
axios.defaults.baseURL = 'https://127.0.0.1:8000/api'
to
axios.defaults.baseURL = 'http://127.0.0.1:8000/api'
Note: Make sure it's exactly same URL and Port. You can see that in terminal where you start the laravel application (php artisan serve).
I am running a local webserver, which runs an XHR request to an ngrok server, also run from my PC.
I'm getting XMLHttpRequest cannot load http://foo.ngrok.io/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.
It appears the ngrok FAQ mentions CORS headers, but only in relation to basic auth - it doesn't mention how to set the headers so I could test my app in development.
How do I change ngrok's CORS options to allow loading requests from localhost?
UPDATE: different use case. BOUNTY FOR THIS SOLUTION:
I am getting the following error:
login.php:1 Access to XMLHttpRequest at 'http://localhost/lagin/public/login.php'
from origin 'http://062b-96-230-240-153.ngrok.io' has been blocked by CORS
policy: The request client is not a secure context and the resource is in more-
private address space `local`.
I've looked at Configure ngrok's CORS headers but still not sure how to proceed. When I tried ngrok http -host-header=rewrite 80 it says header not defined.
I've looked at 10 or 12 youtube videos and they all do a great job explaining what CORS is but an awful job explaining how to fix it.
I'm running virtualbox on a windows 10 machine and create a linux virtual machine. On the linux side I am running xampp as a local server.
I am happy to provide more details but I just don't know what additional information is needed.
I am able to see the login page of my site on ngrok but as soon as I make a axios call I get the above error.
Also, I tried //flags/#block-insecure-private-network-requests in chrome and set to disable. When I do that I no longer get the error but the site doesn't work.
ADDITIONAL INFORMATION:
I spoke to ngrok and they say: ...it sounds like your app is trying to call localhost somewhere in a ajax request. You will need to adjust that call to ensure it is being routed through ngrok.
here's what I'm doing:
responseData = sendData2('http://localhost/lagin/public/login.php',emailPass);
and here’s sendData2 (just for completeness)
function sendData2(url,emailPass){
let bodyFormData = new FormData()
for (const [key, value] of Object.entries(emailPass)) {
//console.log(key,value)
bodyFormData.append(key,value)
}
return axios({
method: 'POST',
url: url,
data: bodyFormData,
headers: {'Content-Type': 'multipart/form-data'}
})
.then(function(response){
return response.data
})
.catch(function(response){
return response
})
}
UPDATE: Each time we tunnel into ngrok we get an address like https://2634-96-230-240-153.ngrok.io If we change the send2() call to
sendData2('http://96-230-240-153.ngrok.io/lagin/public/login.php',emailPass);
it works but this requires I change the code each time I have a new tunnel. Would adjusting the CORS policy get around this problem?
I just stumbled across this issue today and was able to resolve it by starting ngrok and including the -host-header flag.
ngrok http -host-header=rewrite 3000
From the docs:
Use the -host-header switch to rewrite incoming HTTP requests.
If rewrite is specified, the Host header will be rewritten to match
the hostname portion of the forwarding address.
First of all ngrok is just a tunnel and not a server so configuring CORS header in ngrok is not at all possible. So any kind of CORS configuration needs to be done at the server level.
For example if you are using a nginx server, you need to configure header in the nginx conf file like:
location / {
/*some default configuration here*/
add_header 'Access-Control-Allow-Origin' '*';
}
By adding this header, you say that cross origin access to your address is allowed from any address as the value of the header is '*'. You can also specify a particular address for which the access to your address is allowed by replacing the value.
For me, in addition to setting up the server, you also need to add to the header on each request sent from the client side
"ngrok-skip-browser-warning": true
With Webpack / react, I used the 'requestly' Chrome extension and set up a rule from the Bypass CORS template. Note that after selecting Templates > Bypass CORS, you need to click Create Rule in the top right of the dialog.
Then fill in the section at the top, "If domain contains <your domain" and make any other configuration changes, then you can save your rule.
If you are using ngrok with nodejs/express.js .
Use this code:
app.use(function(req, res, next) {
res.header("Access-Control-Allow-Origin", "YOUR-DOMAIN.TLD"); // update to match
the domain you will make the request from
res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-
Type, Accept");
next();
});
Replace "YOUR-DOMAIN.TLD" with "*" to give access to all urls OR your specific website url.
Refer to https://enable-cors.org/server_expressjs.html for more details
Getting ngrok to work took a little time to figure out but it's actually quite easy.
In chrome there is an option to turn off CORS. In the chrome address bar go to
chrome://flags and look for Block insecure private network requests.
This needs to be disabled.
Second, in my ajax request I had used an absolute path and this needed to be changed
to a relative path.
REMEMBER:This is for running localhost and exposing it to the web
I am trying to connect to a websocket on server.domain.com from trial.domain.com
NS_ERROR_DOM_SECURITY_ERR in Firefox:
"[Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "https://trial.domain.com/home Line: 454"]"
when I am trying to make a WebSocket Connection:
try {
if (window['MozWebSocket'] !== undefined) {
socket = new MozWebSocket('ws://server.domain.com/chat');
} else {
socket = new WebSocket('ws://server.domain.com/chat');
}
trails = 0;
} catch(err){
trials++;
}
This happens by Browsers that is applying security policy that prevents of use any access to external domain that the page is hosted it self.
This occurs in scenarios when you are trying to get important connections from SSL area to non SSL and another domain (don't know if same domain will solve the problem) - that is your case. But there is more of possible scenarios of this.
This is browser related error, and it is browser who throw this error, and there is no problem with connection it self.
You have to host your WebSockets server under same domain as the http server. If that is not possible, there is few ways you can go:
If software is for inhouse use and settings in browsers can be done for use, then you can disable cross-domain security policies:
Firefox, under "about:config" set s"ecurity.fileuri.strict_origin _policy" to "false".
Chrome, run with flag "--allow-file-access-from-files"
If you have access to DNS settings of your domain, you can create sub forwarder and it will look like you are connecting to the same domain. Not sure about this option on practice, but it looks well.
I am deploying an app on Heroku and trying to determine whether the request coming in is secure (request.secure). This is initially returning false on heroku because nginx handles the SSL work and communicates over plain http to the app server. So to let play read the headers that let is know it's a secure request I add:
XForwardedSupport=127.0.0.1
To application.conf as recommended in the play message boards. However, then all requests (except for images) fail with no error. It seems to be something fundamental happening before it hits the play logs. Has anyone experienced this?
I don't think Play supports the way that requests are forwarded (proxied) on Heroku via the XForwardedSupport configuration parameter. That would need to be set to the address of the Heroku load balancer and there isn't a way to configure that pre-runtime. Instead, you should just look at the x-forwarded-proto request header to determine if the request to the Heorku load balancer was via http or https. Maybe something like:
Boolean secure = false;
if (request.headers.get("x-forwarded-proto") != null) {
secure = request.headers.get("x-forwarded-proto").values.contains("https");
}
System.out.println("secure = " + secure);
BTW: Heroku's cedar stack doesn't use Nginx. It uses MochiWeb, an Erlang-based web server.
thnx big time! you saved hours of struggling with heroku+play!
I can confirm that when you set this in application.conf
XForwardedSupport=all
heroku stops complaining with SIGTERM
As pointed by #Dan Carley ticket on https://play.lighthouseapp.com/projects/57987/tickets/1406-play-123-124-playmvcrouter-does-not-fully-support-proxied-ssl#ticket-1406-4
When hosting on Heroku, (as pointed by Mirko) setting XForwardedSupport=all in application.conf works.