I'm currently working on a React project. The development server (Bottle/Python) for the project is hosted remotely, and my React dev-server is localhost. Part of the authentication process for the application involves setting a cookie on login, but because of same-site and secure rules that cookie is not being set, meaning that my dev frontend can't access any of the data that it needs.
Myself and the server engineer have added SameSite=None to the cookie as well as secure, but because my localhost is not https the cookie is still not being stored properly (I get the error message "this Set-Cookie" was blocked because it had the "Secure" attribute but was not received over a secure connection").
There are no issues when the app is deployed because everything is on the same domain, but for now we're stuck - we've been trying to solve the issue for several hours but can't seem to get it.
My question is - what is the best development practice if you need to access a non-local development server, but can't actually just have your own version of the server running on your local machine?
Do I:
Need to make my localhost https somehow?
Need to make the dev-server domain https?
Need to install the server locally because there's just no way to do this?
Apologies if this is a noob question, it would be great to have some advice.
Many thanks.
The short answer is:
No
Yes
No
You can run your app on http://localhost:port. Assuming response from your dev server has in response headers Set-Cookie of the cookie which has Secure flag, your dev server URL has to be https in order to have the cookie accepted by the browser.
I have this setup and it works just well.
Regarding CORS (as mentioned in the title of the question): you have to have you server configured to accept credentials and to have allowed origins configured. The client app when doing XHR request has to have withCredentials:true. Check the points 2 and 3 in my post for details.
Also note, that if you are using Chrome you can bypass for development purposes the requirement to have SameSite=None and Secure by disabling the flag "Cookies without SameSite must be secure", also detailed here
Related
If I make a request to my Daphne/Django server in Postman or the Android app we're developing, Daphne serves the certificate, but it's rejected. If I first make a simple get request to https://letsencrypt.org/ and then make a request to my server, the certificate is accepted.
How can I make sure a client will trust my certificate, even if it's the first time this client is seeing a certificate issued by this CA?
Everything bellow can serve as a history of how I studied the problem.
Original title: SSL Certificate works in browser but can't be verified by Postman
I have an AWS EC2 instance running Ubuntu 18.04, with python 3, Django, a bunch of project dependencies, Daphne running with ASGI, with a certificate by Let's Encrypt. Daphne is using port 8000 for HTTP and por 4430 for HTTPS, iptables is configured to redirect requests from port 80 to 8000 and from port 443 to 4430. Django is configured to enforce secure connections with SECURE_SSL_REDIRECT=True in the settings.py file.
There's a "Site in Construction" temporary page being served, and it's properly accessible from every browser and every device I tested so far. If I explicitly type http, I get redirected to https and the certificate is accepted. Every browser I tested (Firefox, Brave, Chrome, Chrome for Android) says cert is good.
Curl outputs the HTML content returned from the server. I don't know if it accepts the certificate or ignores it.
The Problem
Postman, however, says "Error: unable to verify the first certificate". Only works when I disable "SSL certificate verification", which doesn't answer my question: why Postman is unable to verify my Let's Encrypt certificate?
I'm building an API that runs on the same server, using the same domain, and it's meant to be consumed by a mobile app. Currently, the Android app is throwing a "TypeError: Network request failed", which I suspect could be caused by the same thing Postman is complaining about.
When I spin the server locally and configure 1) the app to use http://localhost:8000 and 2) the server not to enforce SSL, it works in browsers, Postman and in the Android app.
I've being looking for answers in many places for days, so any clue will be very welcome.
EDIT
Interesting clue:
If I make a request to my Daphne/Django server, it servers the certificate, which is rejected. But if I first make a request to https://letsencrypt.org/ and then make a request to my server, it works!
This pattern holds true in both Postman and our Android app.
It also happens when I first make a request to https://alloy.city (instead of letsencrypt.org), which is served by a Node.js app, and uses a certificate also issued by the Let's Encrypt CA.
So maybe the question should be: how to configure my server to politely invite clients to add the CA that issued my certificate if they hadn't done it yet?.
Apparently, that's what my Node.js server does.
Yes, in settings, tap ssl verification off
File > Settings > General > SSL Certificate Verification > off
I am trying to use facebook sdk for facebook login.
I gave http://localhost as Valid OAuth Redirect URIs but it throws the following error
HTTPS is required for all Redirect URIs.
I used this future few days ago it worked fine. but now it throws this error
And I am not able to disable
Enforce HTTPS
option
I ran into this issue with my Rails app that I usually run with http://localhost:3000.
To use https, I used ngrok which allows you to use https by providing a tunnel. To do this:
I went to their website and downloaded their program
I extracted the file for the program
In my console, I went into the directory where ngrok was extracted to and entered 'grok http 3000' on my Windows machine, others may use './grok http 3000'
After entering that, ngrok provided a https address which I put into the Valid OAuth Redirect URIs field in Facebook
Then I started my server and was able to access it using that https address instead of localhost:3000
yep, they changed that recently :-(
For testing the login flow locally I installed a self-signed certificate
https://letsencrypt.org/docs/certificates-for-localhost/
btw, I doesn't have to be trusted by the browser if you're OK with a one time security warning.
Don't use this certificate in production!
I am trying to test OAuth2 authentication using Django 1.11.4 and Django OAuth Toolkit. After following the tutorial (like, literally verbatim) the consumer application on heroku refuses to exchange the code generated in order to grant me an authentication token with a non-specific error.
After much fiddling, I found out that even on DEBUG configuration the OAuth framework would through an insecure transport protocol exception (as it was through local Django server which uses http not https). Thus I ported the web application to an apache instance which was SSL enabled but still the consumer app throws me an unspecified error.
Please do note that I am following verbatim the tutorial outlined here and the heroku application when I have my secret key and everything setup as shown in the docs. Although the authorization link (and database entry) is generated when I go back to exchange the code for a token things fail, with a non-specific error. The result looks like this (the full server address is omitted due to obvious reasons).
Any idea on what might be wrong?
I have a similar error when using http for localhost, and I suspect that it is the same issue. I am using Chrome, and in the Network tab I can see that the POST to /o/token throws a CORS error. Looking into the JavaScript Console
Access to XMLHttpRequest at 'http://localhost:8000/o/token/' from origin 'http://django-oauth-toolkit.herokuapp.com' has been blocked by CORS policy: The request client is not a secure context and the resource is in more-private address space `local`.
POST http://localhost:8000/o/token/ net::ERR_FAILED
This is a Chrome security setting:
Block insecure private network requests.
Prevents non-secure contexts from making subresource requests to
more-private IP addresses. See also:
https://developer.chrome.com/blog/private-network-access-update/
This blocks http sites from accessing localhost. To remove that block (for testing purposes), open a browser tab with chrome://flags/#block-insecure-private-network-requests and disable the flag.
Interestingly enough the Heroku app supports https, which would solve the issue, but it incorrectly hardcodes the redirect url to http: http://django-oauth-toolkit.herokuapp.com/consumer/exchange/
I'm setting these cookies for a single sign on solution where I have one app running at foo.example.com and a different app running at bar.example.com.
I know that I can set a cookie from foo.example.com for .example.com.
If I had control over bar.example.com I'd just have it recognize a cookie from .example.com. But I have very little control of it.
For what it's worth, the app at foo.example.com is in python and the app at bar.example.com is java.
You can certianly try. However, browsers should not honor this behavior as it is a cross-site cooking attack.
This is not possible. SSO is done using protocols such as OAuth or SAML that imply sending signed messages between the endpoints and/or communication between them. There is no way to do this on the "client side".
I work on a project which make ajax query to a webservice so I use fiddler to see JSON responses.
But I have encounter troubles using Fiddler. When I launch it on my laptop, Dropbox can't synchronize my files anymore but I can debug my ajax requests. The real problem is when I use Fiddler on my desktop computer, all my requests to my WebService are blocked. My WebService runs on localhost.
I don't understand how it works, can you help me?
Dropbox connections don't work because that application uses a feature called "Certificate Pinning" that reject's Fiddler's HTTPS interception certificate. Why this happens is discussed in the Fiddler book, but you can configure Fiddler not to decrypt dropbox.exe's connections which resolves the issue.
To avoid blocking DropBox App traffic while Fiddler is running, you can use Tools > Fiddler Options > HTTPS to either only decrypt Browser traffic or you can configure Fiddler not to decrypt traffic to *.dropbox.com.
The issue with your "WebService" is almost certainly completely unrelated. You need to be far more specific for anyone to help: What is the client? What is the service written in? What do you see in Fiddler when this happens?