I have directus API and admin app on localhost and I have frontend React app on localhost:3000. When I try to login via client.login method from React interface directus sets cookie to localhost (its admin app origin). But I need this cookie on localhost:3000 where my actual app located.
Set cookie header is like that:
directus-test-session=4JCvIJhNxCovLAvCwkSulylc8ZYq1iok4EQ3%3A%3A5b84ad5310ba25a7129ed57448136e13; path=/; expires=Sat, 04-Jan-2020 14:06:49 UTC; HttpOnly
Also google console provides warning like below:
A cookie associated with a cross-site resource at http://directus.test was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure.
I need to set cookie to localhost:3000. How can I do this? Thank you in advance.
I'm not sure if Chrome allows you to set cookies to localhost on a specific port at the time of writing*
As for the warning thrown: we can't set the SameSite attribute as that will kill support for cross domain cookies entirely. You can either host your end project on the same (sub)domain as Directus or use the JWT mode for authentication instead. (When using client.login, set mode = 'jwt').
We can consider making the cookies Secure by default, but that would possibly hinder localhost development, as that requires a HTTPS connection for the cookies to be sent.
* Chrome (and the other browsers) have been updating their cookie policy very frequently lately to fight third party tracking.
Related
I am using cypress for e2e testing with the session storage feature enabled.
Until recently the only two cookies in the project were "access_token" and "refresh_token". Now I added 2 more cookies which store some data which will automatically be written and read while you're using the website.
When browsing the website with any native browser (chrome, firefox, edge), no cookies get sent by the frontend to the backend in the request. Only the "access_token"s content will be used as the Authentication bearer.
When browsing in any browser inside cypress or letting cypress automatically browse, all cookies which exist will be added to every sent request. Not only requests sent by cy.request() but also the requests which the frontend natively sends.
This is a problem since the header size gets to large and the backend wont accept it. The quickfix was to increase the accepted header size in the backend but I'd prefer not sending the cookies at all.
Is there a way to tell cypress which cookies to send or prevent sending cookies at all? I don't really care which cookies will be stored in the cypress session. Only which cookies get sent.
EDIT:
All cookies use "strict" same site settings.
When testing against a deployed system https is used but with an invalid certificate.
When testing against a locally running system http is used.
The cookies only get sent when running cypress against a local system (localhost).
Using samesite=strict means that the cookie will never be included in requests to other sites, so I guess that is your core problem here. You need to use samesite=none to get cookies included in HTTP POST Request across sites.
We have a site that uses first party and third party cookies. Security has pointed out that several of our cookies are not httponly and not secure. After looking the web.config file I see this:
<httpCookies httpOnlyCookies="true" requireSSL="true"/>
Hitting the site and using Google Dev Tools shows the cookies are still not marked as httpOnly or secure.
Shouldnt this setting force all first party cookies to be rendered as httpOnly and Secure? Or am I missing something? Any reason these cookies would not be httpOnly/secure? I also set this via IIS at the server level, but no change in the cookie's status.
Barry Dorrans has nice page documenting the forthcoming changes by Chrome 80 (and others) to samesite cookie extensions and how it might affect OpenIdConnect auth flows in .net / .net core based web apps.
How will the SameSite cookie extension changes in Chrome 80 affect IdentityServer4 users?
What action (if any) do current identity server users need to take for this coming change to cookie behavior? Currently running IdentityServer4 2.13 with authcode and implicit flows.
You will get below console warring in Google Chrome and your Identity server failed to redirect to Client that could be React App or Angular App for Chrome version 80.
A cookie associated with a resource at was set with SameSite=None but without Secure. It has been blocked, as Chrome now only delivers cookies marked SameSite=None if they are also marked Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5633521622188032.
To Fix this , you need to do changes mention in below link -
https://www.thinktecture.com/en/identity/samesite/prepare-your-identityserver/
NOTE : For .Net Core 2.2 , set SameSite = (SameSiteMode)(-1)
, For .Net Core 3.0 or above , set SameSite = SameSiteMode.Unspecified
Also , for Chrome 80 version , add this extra condition -
if ( userAgent.Contains("Chrome/8"))
{
return true;
}
I created a cookie in a java filter and added back to the response
response.addCookie()
before returning to the client node.js application. This web application is accessed using a localhost URL in the browser. After reading about cookie domain issue while using 'localhost', i did not set any domain or path in the cookie, while creating it.
Now the Chrome or Firefox browsers don't show-up the cookie in the browser. All my URLs are http://localhost but, each page having different path.
Step 1: During a request to http://localhost/app/login cookie is created and set in the response
Step 2: When the page loads after response, no cookies are shown in Chrome
Step 3: During the next request http://localhost/app/customer the previously created cookie is not recieved when trying request.getCookies().
Step 4: Before returning back to client application, a cookie is created
Step 5: Now the cookie created in Step 4 is shown in Chrome
Step 6: The next request is also sent to http://localhost/app/customer , now the cookie created in step 4 is recieved in the server as well
If cookie creation for localhost is an issue, how does it work for Steps 4-6 only ?
How can i make the created cookie available to all paths under the
localhost domain ? I tried using cookie.addPath("/") but, no change.
Note: Due to admin privilege issues in my development machine, i am not able to set-up a domain name to my localhost IP in etc/hosts file.
In your Java server, you should call cookie.setPath("/") before adding it to response.
Such cookie will match all request URIs. It's a pity that it is not the default behavior.
I have a more detailed explanation of cookie path here - http://bayou.io/release/0.9/javadoc/bayou/http/Cookie.html#path
Not sure path is the issue. Path does not affect whether a cookie is created; it only determines whether it is presented. If cookies aren't showing up in the browser's cookie jar they are being rejected for some reason other than path.
Chrome will not accept cookies for localhost because it does not accept cookies in the top level domain. The domain in the URL has to have a dot in it somewhere. So you could either add a hosts entry (recommended) or just trying using 127.0.0.1 instead of localhost.
Also, none of this will work if the cookie is marked as secure or is being set with a domain attribute. If either of those is the case, you MUST use a hosts entry instead of localhost or 127.0.0.1.
I am trying to mark the ASP session ID cookie as HttpOnly but can't seem to find a way to tell if it is working. The environment I am trying this in is as follows:
OS: Windows Server 2003
IIS: 6
ASP Version: ASP 3 (Classic ASP)
In order to mark the cookie as http only, I followed MS KB
As per our architect's suggestion, to test whether this works, a javascript document.cookie should not be able to read the ASPSESSIONID* cookie. My issue is that javascript:alert(document.cookie) still echoes the ASPSESSIONID* cookie, albeit it appears to be encrypted(?)
I also tried to do this via Response.AddHeader "Set-Cookie" but can't determine what value to give for this header to mark all the cookies OR AT LEAST the ASP Session ID cookie as HttpOnly.
Help!!!
Just came across this issue because of a "new" PCI compliance item. It's a bit clumsy but this seems to work:
<%
Dim AspSessionCookie
AspSessionCookie = Request.ServerVariables("HTTP_COOKIE")
If len(AspSessionCookie) > 0 Then
AspSessionCookie = "ASPSESSIONID" & Split(AspSessionCookie,"ASPSESSIONID")(1)
If InStr(1,AspSessionCookie,";") then
AspSessionCookie = Split(AspSessionCookie,";")(0)
End If
Response.AddHeader "Set-Cookie", AspSessionCookie & ";HttpOnly"
Else
Response.redirect(Request.ServerVariables("URL"))
End If
%>
You seem to be confused between SECURE and HTTPONLY
These are different. The MS KB article you refer to is for SECURE.
Setting a cookie SECURE will stop IIS/Browser sending the ASP Session ID over HTTP.
Setting a cookie HTTPONLY will stop script (javascript) from accessing the value in most browsers.
There is a very GOOD reason to set HTTPONLY on a sessionID cookie. It help prevent theft of the users sessionID cookie, which could lead to session hijacking. That is why major browsers have implemented it.
I don't think your architect is correct regarding accessing the cookie in javascript.
There is no reason to stop javascript running in your page from accessing the cookie any more than javascript accessing the rest of your data in the HTML.
The purpose of adding the secure qualifier to a cookie is to prevent it from being sent in an unsecure request.
Oridinarily cookies set when the client is connected using https will still be sent when requests are made to the same server using plain http. The marking a cookie with the secure qualifier when its Set indicates to the client that it should only be sent in subsequent requests if those requests are using https.
Hence to test your setting get yourself a copy of fiddler, with that running hit the server over https then in the same browser session hit the same location with just http. Fiddler should show the second request going to the server and there should not be an ASPSESSION cookie present.