I'll attach an image to illustrate what I'm looking to do:
Note: The above photo should say "Redirect to HTTPS"
To preface, this is the following is the technology stack
DNS: GoDaddy
Proxy: Cloudflare
Client: React app hosted on Heroku
Server: Flask API hosted on Heroku
The flow at least to my understanding is this:
User enters in domain.com in browser and GoDaddy forwards all traffic to Cloudflare so that the site is viewed securely
Cloudflare then forwards the traffic to where the client is hosted
Once client is loaded, it makes a request to the server to receive a CSRF token. The CSRF token is generated by a method within flask-wtf. A session is created in the server and in the response, the CSRF token is attached to the header
Here things gets weird
Since the response received on the client never had the CSRF token attached to the header and no cookie was set on the browser, I would assume that the response goes to Cloudflare before the response hits the client. As a result, the CSRF token is never received. Not sure why this is the case.. But after a bit of research, I've discovered that Cloudflare does this by default.
It seems that a work around would be to use Cloudflare Workers, but that seems only available if their DNS is being used. Ideally, I would like to stick with GoDaddy.
I was wondering if anyone else experienced this and found a different solution.
Related
My API and my frontend are hosted on render.com but at different subdomains. When I log in, my API send a cookie with SameSite=None, Secure=true and frontend domain. But Chrome refused to set the cookie and block it. How to handle this situation? What I am missing?
I am using AWS ALB for OIDC authentication, and once authenticated it lands to my backend application where i create a session save it in redis and return the session cookie back to front end.
The front end uses the cookie to commuicate with my backend.
After 10 minutes if the session is expired. Then i want to redirect the page login page.
My question is should i handle the session expiry in my code or does AWS ALB has some intelligence in it to know that my sesion is expired and redirect to logic page.
If i have to explicitly redirect form my code. DO i need to get location header and statu code as 302 as below.
/login is listener in ALB which will authenicate to OIDC
response.getHeaders().setLocation(URI.create("/login"));
response.setStatusCode(HttpStatus.FOUND);
However, when i redirect to /login. which is path route configred in ALB to authenticate via OIDC. I get 404 0r 400 not found from Oauth provider . Is it because of setting location header am not sure
Your session is handled by your backend services and ALB has no knowledge nor access to it. So, you should also handle session expiration in your code.
I have a client requirement for whitelabelling, for which I need to forward all requests at hello.example.com to data.value.com.
The url in the browser will show hello.example.com but the page loaded will be of data.value.com.
hello.example.com is hosted on GoDaddy and I have made the corresponding entries in GoDaddy
data.value.com is hosted on AWS with a Cloudfront Distribution.
Now, when I hit hello.example.com I get a 403 error from Cloudfront with the following error Message:
403 ERROR
The request could not be satisfied.
Bad request. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
When I do ping or traceroute on hello.example.com, I am able to see that the ping happens on data.value.com.
What configuration changes do I need to make in order to re-direct my domain requests.
I have Elasticsearch (AWS Elasticsearch Service 7.7) running in my AWS VPC.
I'm trying to access Kibana, from a web browser, on my laptop at home.
I followed these instructions, to setup an nginx reverse proxy:
https://medium.com/#k.ashu403/aws-elasticsearch-nginx-reverse-proxy-for-accessing-kibana-86292edc6f14
My config file based on this one (authored by the blog post author):
https://github.com/kin-kins/AWS-services/blob/34c94abeaac5e8e7f5371f5d0df3f49c0417ec56/nginx_reverse_proxy.conf
Everywhere that file shows 3.226.189.187, I have replaced it with the external IP of my reverse proxy.
Everywhere that file shows vpc-ngelasti-qmazoh6hzvpxiludpnzasoi2nu.us-east-1.es.amazonaws.com, I have replaced it with the fqdn of the Kibana instance running in my VPC.
(And nginx has been restarted).
If I then access, my equivalent of: http://3.226.189.187/_plugin/kibana/, I get properly requested for my username & password, and I pass basic auth.
It then redirects to the equivalent of http://3.226.189.187/_plugin/kibana/login?nextUrl=%2F_plugin%2Fkibana%2F#/
If I put in an incorrect username or password, it tells me that it's wrong.
If I put in the correct username & password, it sends me right back to http://3.226.189.187/_plugin/kibana/login?nextUrl=%2F_plugin%2Fkibana%2F#/
In short, I keep getting prompted for the username/password (i.e. redirected to the login page). I assume something is wrong in the nginx conf, but I'm not sure, and have spend a lot of time w/ trial and error, and haven't made much progress. (AWS Elasticsearch Service is configured for username/password auth, which works within the VPC, for Elasticsearch)
What worked for me:
add https (443) on the inbound security group with your ip/office ip range/all traffic
generate a certificate (be aware chrome doesn't like self signed, might have to use firefox)
change your nginx config to use https (port 443) instead of http (port 80) and add the path to the certificate in the config as well.
Example config, namely the listen 443 line as well all the lines starting with ssl
Explanation:
When logging in a security cookie is supposed to be set with a token but it won’t be set when using http for security reasons, changing to https will allow this cookie to be set.
This can be seen by looking at the network request to _plugin/kibana/api/ui_metric/report and looking at the headers and response. It shows the redirect back to log in as well the session expired message.
I have a AWS Cloudfront hosted webpage which takes static pages from S3 and makes calls to custom origin (ALB) for dynamic data. There is OIDC authentication enabled on ALB, so calls to custom origin (my API) passes via rules set at ALB.
In a particular case when my request to custom origin is unauthenticated I am redirected to IdP for login and after successful login I get the cookie in the response header, as this request was sent to IdP from ALB - the issued cookie has domain as ALB DNS. In order for my webpage to use this cookie I have to redirect the call to Cloudfront URL. Now the cookie was issued to ALB which has a different DNS and my Cloudfront URL has a different DNS therefore I am unable to use the cookie.
I tried to catch the cookie value but because it is issued for a different domain i am unable to catch hold, also as a part of design I feel that is wrong. Has some one faced similar type of issue.
AWS ALB OIDC sets session cookie for the same request host domain for which you configure the authentication action in the listener rules.
Also, they set a http only secure cookie, meaning you cannot access it via client side Javascript at all.
Considering this along with your setup, it seems you actually need a (tiny) backend for your web page, so that you can access the response cookie when you make the API call to the mentioned custom origin internally from this backend.