I found out that for some users of my website the _ga (client id) cookie is empty while I really need it in my script for 100% of users.
I found this out by logging what's happening in my PHP script. This is strange to me, because for me the _ga cookie is always present, no matter which browser I use.
1) Why can the _ga cookie be empty?
2) Is there any way to force creating it? Or maybe there is another way to find out the client id of the user on the server-side?
If javascript or cookies are disabled on client browser cookies always will be empty. You can implement additional logic on server to form an id from IP and/or User-Agent header of request if cookies are empty.
Related
I have a server side application that uses cookies for session management. The browser has some script that sends an ajax request to add information to the session. This is working well and in production.
The business wants to be able to insert this application in other companies' websites via iframes. ie myapp.com is in an iframe in otherbusiness.com and when the user clicks a button in the application in the iframe launched from myapp.com, it sends a request with a cookie that contains the session id to update the user's session on the myapp.com server.
For the browser to be able to send a cookie, 3rd party cookies needs to be enabled by setting the cookie options of SameSite=None and Secure. This works for all browsers except Safari.
Safari no longer accepts 3rd party cookies.
The only solution I can come up with is to use session ids in the URL but this is a little cumbersome.
Can anyone suggest a better option or perhaps a good implementation of session ids in the url?
I used hidden html fields to pass the session id and expiration.
My server side code checks for a cookie if it cannot find it, looks for the session id and expiration in the hidden fields.
This avoids security issues with passing the id in the url. It is a little clumsy to implement but it works.
i'm facing a few problems when i authenticate usign cookies to store the token, those cookies should be delivered between subdomains, for example, i have my auth code deployed in a subdomain named services.mydomain.co and my frontend in subdomain named apps.mydomain.co,
when someone authenticates, then my auth code creates a cookie with the tag Domain like this: Domain=.mydomain.co in order to enable it to be delivered between all subdomains of mydomain.co, but the cruel reallity is that it is not working, even the browser isn't storing the cookie.
the cookie it's successful delivered in response header after authenticate but the browser isn't storing it.
im creating the cookie this way:Set-Cookie: myKey=myKeyValue;path=/;httpOnly;Max-Age=1555520000;Domain=.mydomain.co;sameSite=none
hope someone could geve me an advice and sorry for bad english.
From your example, you are setting SameSite=None without Secure. This is invalid and browsers (Chrome, Edge, Firefox, etc.) will begin rejecting this.
However, you should check DevTools in Chrome on your site to see the specific error. You can check both the Console and individual requests in the Network tab to see issues with a given cookie.
You can find more detail on https://www.chromium.org/updates/same-site/test-debug
I'm setting a cookie in a response from my web service. The set-cookie header is coming through, and I can see the cookie in the network tab in Chrome, but the cookie isn't being stored. It doesn't show up in the resources->cookies tab, and the cookie isn't sent with subsequent requests. Nothing shows up in the JS console. I've also tried leaving the domain field off the cookie, but it still isn't stored.
Is there a way to debug the browser to understand why the cookie was rejected from being stored?
Turns out it had to do with the way I was making the request. I expected fetch() to work the same way as XHR requests. Setting credentials: 'include' on my fetch call resolved the problem. See 5.6.14 of the fetch spec
I created a Google site page with 5 links on it. Is it possible to create on my site a script or something that stores in a cookie the link on which the user has clicked, and then the next time he will connect to the page, he will be automatically redirected to the link he clicked on ? For information, the user connect to the site with his Google email account.
How can I do that please?
Thank you very much in advance for your help
While it is possible to read cookies and redirect using JavaScript inside a Google Page (using widgets), browsers will not allow you to set cookies for a completely different domain for obvious security reasons.
Related:
How to set a cookie for another domain
Cross-Domain Cookies
What's your favorite cross domain cookie sharing approach?
You could theoretically try and send an AJAX request from the Google Page with a "where should I direct this user to?" and expect a URL or a null.
See:
CORS $.ajax session cookies (access-control-allow-credentials & withCredentials=true)
Cross domain POST request is not sending cookie Ajax Jquery
But overall, your task is not as straightforward as it may seem. The browser will, fortunately, not play along.
Classic problem, a web app has secure and insecure pages (ie. account page is secure (HTTPS) and faq page is insecure (HTTP)), as a developer, I want the user to see a customized login button on the insecure pages (ie. it says 'click to login' if you are new to the site and 'Welcome User click to see your account' if you have a session.
To do this, I have secure cookies set by the server sent only when on the account page, but that account page (via jQuery) will also set an insecure cookie based on the secure one. The insecure cookies can be used by the browser to update the login button (via Javascript).
I am using a random string (randomized on the server each time) for the path to prevent the cookie from ever being sent over the wire. This data is just a username so it's not critical that it is completely locked down, however, it should still be guarded.
Cookie set here using jQuery (jQuery cookie plugin):
$.cookie('userLoggedIn', 'username', { domain: '.example.com', httpOnly: false, path: 'DFKLJGHDFDLFKHGAFDAKDJFH', expires: [one year], secure: false });
So far so good, but to a hacker, does path randomization work to prevent the stealing of insecure cookies?
I know that this is a very old question, but I will try to answer it.
Yes and No.
It doesn't necessarily need to be completely random - the only reason for it to be random is to make sure user never tries to get to that url, nor any ajax request goes there. To make sure that happens, you can use e.g. an UUID in the path.
You also need to make sure you control ALL of the JS on your domain.
That way the cookie will never get sent over the wire (the only way for it to get sent over the wire is for your JS to read it off document.cookie property and attach it or somehow send a request for that randomised URL).
A hacker won't be able to read the cookie, because browsers protect cookies from JS executed from other domains (protocol://domain:port combination has to match).
So the only way left to read off the cookie is to have access to the machine, then cookies can be read from disc as it is saved as plain text. But there are way more security vulnerabilities that come with having access to the user account.
So to answer your question, it is quite secure, but you have to keep in mind the vulnerabilities that come with such a solution.