Cookie not being set on angular client - django

I have a backend app in django python and it is being served on http://localhost:8000.
I have a angular frontend which is being served on http://localhost:4200.
I have disabled CORS on django.
On hitting the login api on http://localhost:8000/auth/login/, I am getting a valid response
along with the Set-Cookie header.
Here is my angular code to print the cookies:
this.http.post<any>('http://localhost:8000/auth/login/', this.LoginForm, { observe: 'response' }).subscribe(response => {
console.log("response is ", response);
var cookies = this.cookieService.getAll();//('cookies');
console.log("cookies is :", cookies);
It prints an empty object on console.
How do I make this work? I want to use cookies for authentication.

You are trying to set cross domain cookies, which will not work straight away. There are a few steps to follow to be able to do that.
Set withCredentials: true when making the authentication request from angular
this.http.post<any>('http://localhost:8000/auth/login/', this.LoginForm, { observe: 'response', withCredentials: true })
Configure your server to return the following CORS headers: Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: http://localhost:4200
Note
One of the cookies that you are setting is HttpOnly. As such, you cannot access it from Javascript (see documentation).
You may not need to access the cookies with JS anyway. If you just want to send the cookies in the next API requests, just pass withCredentials: true to HttpClient other api calls
this.http.get('http://localhost:8000/path/to/get/resource',
{ withCredentials: true }).subscribe(response => {

Set-Cookies:
In the example in the Question, both client and server are in the same domain, localhost.
On deployment, this may not be the case.
Let us assume the domains as below,
Client : client1.client.com
Server: server1.server.com
A http request from the Angular web app in client1.client.com to https://server1.server.com/api/v1/getSomething has Set-Cookie: JSESSIONID=xyz in the response header.
The cookie will be set on server1.server.com and NOT on client1.client.com.
You can enter server1.server.com in the URL bar and see the cookie being set.
withCredentials:
There is no need for the angular app to read the cookie and send it in the following requests. withCredentials property of http request can be used for this.
Refer: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
Example:
public getSomething(): Observable<object> {
const httpOptions = {
withCredentials: true
};
return this.http.get(`${this.serverUrl}/getSomething`, httpOptions);
}
Refer: https://angular.io/api/common/http/HttpRequest
withCredentials will set the cookies from the server's domain in the requests to the server.
As mentioned before Set-Cookie: JSESSIONID=xyz in the response from server1.server.com will be set in server1.server.com. The Angular app in client1.client.com need not read it. withCredentials will take care of it.
cross domain issues:
When the server and client are in different domains, using withCredentials may not work in all browsers, as they are considered as third party cookies.
In my recent testing on May 2020, I found that withCredentials is not working in certain browsers when the client and server are in different domains.
In Safari, the issue occurs when "Prevent cross-site tracking" is enabled (by default). The issue is prevented by disabling the same. https://support.apple.com/en-in/guide/safari/sfri40732/mac
In Android apps, the issue can be avoided by using Chrome Custom Tabs instead of Android WebView. https://github.com/NewtonJoshua/custom-tabs-client , https://developer.chrome.com/multidevice/android/customtabs
Same domain:
Looks like mainstream browsers are moving to block third-party cookies.
Safari - Full Third-Party Cookie Blocking and More
Chrome (by 2022) - Building a more private web: A path towards making third party cookies obsolete
The solution is to have both the client and server in the same domain.
Client: client1.myapp.com
Server: server1.myapp.com
And in the Set-Cookie response include the root domain too.
Example: "JSESSIONID=xyz; Domain=.myapp.com; Path=/"
This will make sure the cookies are set in all cases.

Related

Django CSRF Failed: CSRF token missing or incorrect when using client on localhost

I am using django 3.2 , i had implemented csrf using below link
Link
Everything works fine when using same domain for client and server.
But while testing locally i get the error when sending post, put or delete requests.
I can see csrftoken in the request headers under cookie, but can't see it using document.cookie.
csrftoken is non httponly cookies, still i don't know why it not visible in document.cookie in client side.
You have to add CSRF_TRUSTED_ORIGINS = ["localhost:3000"] inside your settings.py to allow post requests.
I finally got the solution,
Since my backend was running on other domain not on localhost.
I had added proxy for all the requests, so that they appear to be coming from same origin.
In Angular, it ca be done like below:
proxy.conf.json
{
"/**": {
"target": "<your backend url>",
"secure": false,
"changeOrigin": true
}
}
then run using,
ng serve --proxy-config proxy.conf.json

Localhost frontend no longer sending cookie to development backend

I'm trying to connect my local frontend to our development backend hosted in aws.
Everything used to work, and I'm going crazy trying to figure out what happened.
The issue is that the request to the backend isn't passing along the cookie we use for authentication.
We have cors setup and it appears to be working correctly. The Options call returns everything I'd expect
.
but the request just doesn't contain the cookie.
I'm setting the cookie via javascript in the frontend code rather than having the server itself set it. This setup used to work idk why it doesn't anymore.
What are the reasons why a browser wouldn't pass a cookie along?
My checklist includes:
ensuring Access-Control-Allow-Credentials is passed back from the Options request
ensure withCredentials is set on the frontend making the request
ensuring the cookie domain is set to /
We recently added some CSRF protection but I disabled that and still can't get the cookie to be sent.
A soapui call to the backend works just fine.
The issue lied in the samesite cookie.
I deployed my development server to explicitly set samesite=none and things are working again.
axios({
method: "get",
withCredentials: true,
});
adding withCredentials:true worked for me

Why isn't this cookie sent to other subdomains?

We have an authentication API for signing in and a file download API that serves protected files.
The authentication API lives at authentication.api.mysite.com and returns the following header on a successful sign-in:
Set-Cookie: sessionId=QpiYzBXNNhiMZQSdWfKiDM; SameSite=None; Secure; HttpOnly; Domain=.mysite.com
(I have also tried Domain=.mysite.com, i.e. with a leading dot, without luck.)
The file API lives at files.api.mysite.com and allows clients to download protected files given the following request header:
Cookie: sessionId=QpiYzBXNNhiMZQSdWfKiDM
The APIs are used by a web app that lives at something.othersite.com. In the browser dev tools, I see that the sign-in response has the cookie in the "Cookies" tab, so I know it's set. And the cookie is sent to other requests against the authentication API. But no cookies are sent in requests to the file API.
As I understand it (e.g. MDN), if Domain is set to mysite.com (or .mysite.com judging by some other sources) then it should also be sent to api.mysite.com and whatever.api.mysite.com. But it's not sent to other subdomains.
What are we doing wrong? How can we get the browser to pass the cookie set by the authentication API on to the file API?
In case it's relevant: Both APIs use CORS, set up to allow the specific host we're using (not wildcard), allow any method, allow any header, allow credentials, and expose a set of headers I don't think is relevant (Set-Cookie isn't included there, but it made no difference when we added it).
The cookie was correct; the problem was caused by how the front-end called the APIs. The front-end uses axios, and the solution was to use the withCredentials option, e.g.:
axios.post(
url,
data,
{ headers: headers,
withCredentials: true }
)

Why am I getting "Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute"?

In a Chrome warning, it says:
Specify SameSite=None and Secure if the cookie should be sent in cross-site requests. This enables third-party use.
How do I do this correctly using express-session?
app.use(
cors({
credentials: true,
origin: ["http://localhost:3000", "https://elated-jackson-28b73e.netlify.app"] //Swap this with the client url
})
);
var sess = {
secret: 'keyboard cat',
cookie: {}
}
if (app.get('env') === 'production') {
app.set('trust proxy', 1) // trust first proxy
sess.cookie.secure = true // serve secure cookies
sess.cookie.sameSite = 'none'
}
app.use(session(sess))
you are getting this because you are using a resource from another site and that server is attempting to set a "cookie" but, it does not have the SameSite attribute set, which is being reported in newer versions of browsers.
this (may) also be shown if you are trying to access the server page from local computer (xampp), which generally doesn't has SSL installed;
set the header line in your server page (if in PHP) as below:
header("Set-Cookie: cross-site-cookie=whatever; SameSite=None; Secure");
(remember: this must be solved from the server side.)
i got the same issue when run my code in localhost. The affected resource is _ga, _gid, _utma, _utmz. All of them from unpkg.com
and i got marker image leaflet failed request but doesnt affect the page.
since i dont understand what the specific problem so i just delete the affected resource cookies in inspect element and the code will run without notif again.
thought i know if it's better to not answer based by personal experience. just tell me if it's not help at all.
If you are using Google login button or any other identity service add this:
<GoogleLogin onSuccess={() =>()} onError={() => ()} cookiePolicy='single-host-origin'/>

Safari not storing cookie set through Angular HttpClient / XMLHttpRequest

We have an Angular app that makes a request to a resource on another domain (a headless cms api). The flow is as follows:
Spartacus=Angular, OCC=Java backend, Episerver=.Net backend
Call nr 10 looks like this:
getExternalCmsAuthCookie(jwt: string): Observable<any> {
const url = `${this.episerverBaseUrl}/externalauth`;
const requestOptions = {
headers: new HttpHeaders({
Authorization: 'Bearer ' + jwt
}),
withCredentials: true
};
return this.http.post(url, {}, requestOptions);
}
The in the server response we see the header
Set-Cookie: role-token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1NzUxMTE0OTQsInJvbGVzIjpbIkFwaUNvbnN1bWVycyIsIlBhcnRuZXJQb3J0YWxVc2VycyJdLCJ1c2VySWQiOiI4Nzk2MDk0NzkxNjg0In0.Mbvwe5qPIGSvUS-sFzxzPq7PAMed3LJaVeP8hK7eHQI; expires=Sat, 30 Nov 2019 10:58:15 GMT; domain=api.ourepiserver.com; path=/;SameSite=None; secure; httponly
After that all requests to the cms include the cookie and are let through by the server that sends some cms content back. This content can include tags pointing to episerver. This is the reason we need the cookie beause we can't add any custom http headers to resources the browser is downloading through tags.
This is working in all browsers except Safari. There are some duplicate questions (but not as elaborately explaind) but none seems to have any good answers.
Versions of Safari on MacOS 10.14 and iOS 12 have a bug where they will erroneously treat cookies marked with SameSite=None as if they were marked SameSite=Strict. You may be hitting this issue if you are not on the most recent version.
Potentially, this is also just an ITP limitation if you're trying to set a cookie from a third-party domain that the user has never visited in a first-party context.
I would test this by sending a cookie without the SameSite=None attribute to see if it's passed by Safari. If it is, then this is probably a SameSite compatibility issue. If not, it's likely something else.
I'm also assuming your domains are genuinely different sites and not just different origins. e.g. img.example.com and api.example.com are still the same-site. example.com and service.elsewhere.api are cross-site.
If you're hitting SameSite compatibility, you can mitigate this by setting two versions of the cookie or using useragent sniffing. More details on https://web.dev/samesite-cookie-recipes.