This question might be stupid, but I'm a beginner and I can't disable authentication on ngrok. I was having problems with CORS PUTs so, following this https://github.com/inconshreveable/ngrok/issues/196, I decided to use "disable_options_auth" but I can't seem to figure out how. I tried this on the configuration file:
tunnels:
demo:
proto: http
addr: 8080
inspect: false
auth: disable_options_auth
The linked GitHub issue mentions that ngrok didn't alter its config file auth parameter to accept a value of disable_options_auth:
... if this [accepting CORS preflight requests without auth while enforcing auth on all other requests] is the behavior you want, that you should implement the authentication yourself in your application.
If you just want to disable auth entirely that should make CORS preflight requests work, and you can do that by simply removing the auth parameter from your config altogether.
Related
I have a backend service configured as a subdirectory behind a reverse proxy. The backend has its own auth scheme, and it relies on the authorization header being formatted as
Bearer <JWT Token>
in order to validate a session. Unfortunately, the backend reveals what it is to any curious eyes, and doesn't keep any record of auth attempts/failures to filter with, for example, fail2ban.
I would like to hide the backend behind basic auth, so the page details are only loaded for authorized users, and so that I can monitor auth attempts/failures across all my backends with a simplified fail2ban filter.
The problem I'm encountering, is that in order for the client's requests to reach the backend, once it's secured behind basic auth, the Authorization header needs to be formatted as
Basic <base64-encoded username:pass pair>
The moment the client sets this header, though, the backend is unreachable. The backend and the client also have quite a bit of back-and-forth communication, and from what I can tell <UserToken> is dynamically generated for each login session.
I've tried
proxy_set_header Authorization <A statically generated and set JWT Token for testing>
In the location block of the backend. However, at some point in the transactions that result between client and backend, the Authorization header goes from
Basic (with backend asking for credentials)-> Bearer (backend is authenticated and loads a few resources until...) -> Basic (backend is now logged out and reauthenticating causes an infinite loop)
Essentially, as soon as the Authentication header is reset by the client to authenticate with basic auth, presumably for the client's next request, the backend becomes inaccessible. I would like a way to dynamically maintain two Authorization headers with nginx, if such a configuration is possible, and set the header appropriately according to where in the chain between client, proxy, and backend the request occurs.
I've also tried to experiment a little bit with a mapping like:
map $http_authorization $origin_auth {
"Bearer" $http_authorization;
}
and then adding this directive inside the server block:
add_header my-header $origin_auth always;
Just to see if I could store the header for retrieval on one of the client's future requests, or something... scrolling through dev tools though, to examine the header fields, "my-header" never assumes the value of the backend's expected authorization header.
I don't have enough experience with either the http protocol, or nginx, to know if the thing I want to accomplish is even possible, and I haven't found much help in other posts. I have tried throwing about 3 dozen hours of my life at the problem though, without any luck. Any help would be very welcome and appreciated.
I have nodejs express app as backend, and vue app as frontend on my server. I use session cookies for authentication and i just can't get them working on my local dev machine. Cookie is sent in the response but it is not saved by browser. I know that problem is that request origin must be same as host and i have read all the articles/questions related to the issue and i just can't solve it.
On the server, everything is proxied with nginx on https. Cookie is set there and everything works fine, because they are on same host.
My local vite dev server is running on https, on port 5173.
I use axios for api calls and i have set
axios.defaults.withCredentials = true;
Cookie properties are
sameSite:'none',
secure:true,
httpOnly:true,
In express:
app.use(
cors({
origin: ['https://localhost:5173', 'https://my.site.com'],
credentials: true,
})
);
Like i said before, cookie is sent in the response from the server and just not stored on browser because in request header:
host:my.site.com
origin:https://localhost:5173
referer:https://localhost:5173/
How can i solve this?
I followed solution in comments on https://stackoverflow.com/a/46412839/13781306.
It partialy works when i set
sameSite:'none',
secure:false,
Cookie is passed in requests but it is not stored in the browser storage/cookies. Which is fine and solves my issue.
I want to controll authentication with cookies. And In my browser working successfully.
But When I tried to test with postman, Postman doesn't add cookie to new request.
step - I login and response header like that:
But the response cookies tab like that:
And manage cookies window like that:
step - I send a request to unprotected router and I get unauthorized error.
This error started today. I don't remember making any changes to the settings.
Why Im getting this type error. How can I solve this?
I also had this problem, the fix is to remove the secure flag in the cookie when sending cookies from localhost as cookies set as secure can only be sent over HTTPS.
I had this issue when testing a local Laravel Sanctum request to /login.
I had the following .env values set
SESSION_DOMAIN=docker-api-service-name
SANCTUM_STATEFUL_DOMAINS=docker-api-service-name
However these needed to be set to localhost to match the domain of the APP_URL. After this, everything was working fine.
SESSION_DOMAIN=localhost
SANCTUM_STATEFUL_DOMAINS=localhost
Someone mentioned that setting the secure flag to false will solve it, and it will. The explanation however was not entirely correct.
Secure will indeed only work over secure connections (HTTPS). However, it will also work over HTTP if it's done in localhost: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#restrict_access_to_cookies
I am trying to send a GET request from my frontend to an API application. Both are running on my local machine. This is how it's built right now:
backend <===> frontend <=x=> API application
All three parts are running independently from each other in their own docker container and are only communicating with each other via HTTP-requests.
As shown in the top image, the connection between backend and frontend works fine, but between frontend and API application does not.
The stack consists of:
frontend: Node server with vue-js and for requests I use axios
API application: Scala with Play Framework 2.5.14
The API application itself works just find when I send a request to her via curl like this:
curl -X GET api-application.docker/api/user?userId=1 \
-H "Authorization: key" -H "Accept: Application/Json"
But when I call it from frontend, I get a 404 on the OPTIONS call. It also gives me a warning in Firefox related to CORS header Access-Control-Allow-Origin:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the
remote resource at http://api-application.docker:9000/api/user?userId=1
(Reason: CORS header ‘Access-Control-Allow-Origin’ missing).
Therefore I first went into the api application's application.conf and added
play.filters.cors {
allowedOrigins = ["*"]
}
I also tried to exchange the asterisk for http://frontend.docker:8080
This didn't work, so I deleted that entry again and added this line instead:
play.filters.disabled += "play.filters.cors.CORSFilter"
Still no change at all. Now I am wondering if I misunderstood the connection between OPTIONS and CORS? Or did I turn it off wrong? Can anyone help me out?
EDIT:
More stuff I tried while waiting for answers, all without success:
I changed the entry in application.conf to:
play.filters.cors {
allowedOrigins = null
}
404 on OPTIONS request indicates your CORSFilter is not enabled. Since you are using Play 2.5 you can enable it by adding
libraryDependencies += filters
to your build.sbt, and by creating the following app/Filters.scala file:
import javax.inject.Inject
import play.api.http.DefaultHttpFilters
import play.filters.cors.CORSFilter
class Filters #Inject() (corsFilter: CORSFilter)
extends DefaultHttpFilters(corsFilter)
By default everything is allowed so there is no need to modify application.conf until you decide to start locking down access. You should NOT add play.filters.disabled += "play.filters.cors.CORSFilter" as this disables CORS support.
The reason why your curl request works fine is because non-browser HTTP clients do not enforce Same-origin policy (see related SO answer), thus CORS does not apply in the case of curl.
404 on OPTIONS request means that the following route is not found:
OPTIONS api-application.docker/api/user
The browser automatically sends this preflight request before sending the corresponding GET request. This OPTIONS route will be automatically taken care of by Play's CORS support once enabled.
I just setup the example from https://github.com/simplabs/ember-cli-simple-auth-example using Cloud9 and I get a 400 Bad Request error when I try to login.
I'm pretty sure this is due to fact that Cloud9 only opens port 80 (as referenced in this note from http://log.simplabs.com/post/90339547725/using-ember-simple-auth-with-ember-cli:
As the OAuth 2.0 authenticator would by default use the same domain
and port to send the authentication requests to that the Ember.js is
loaded from you need to configure it to use http://localhost:3000
instead.
Unfortunately I don't know how I might work around this. Any ideas?
Add the host to the whitelist in the config:
window.ENV['simple-auth'] = {
crossOriginWhitelist: ['http://some.other.domain:1234']
}
More info in the Cross Origin Authorization section of the docs