Having a very hard time with cookies on iOS. This issue has plagued me for a month now. I have a problem where my cookies are not being returned by Safari on iOS. Other browsers are not a problem.
Unfortunately, in my testing, I haven't been able to reproduce this issue. I have a physical iPhone myself, and can't get the issue to manifest.
What's happening is users are reporting issues where they can't login. My server code has been logging incoming requests, and in the instances where people can't login, the cookies are absent.
I'm wondering if ITP is getting in the way, but as far as I can tell, I've done everything right to satisfy it.
Here's a screenshot of the debug tools. It shows my two cookies ('cvt' and 'h'), with the expected expiration date.
Couple of things I should note. This is for a site hosted on azurewebsites.net, so it's a subdomain cookie being set. Cookies are set to be httponly, secure, and SameSite=strict
Related
I have a Cordova app that uses WKWebView.
I'm using permanent cookies to authenticate with my (rails) server.
The cookies are stored and sent with subsequent requests, and even continue to be sent after app restarts.
However after some time of not using the app, usually a few days, no cookies are sent with any requests, and I need to re-authenticate to get new cookies.
The cookies are set to expire in 20 years, so I think there must be some other mechanism that is clearing the cookies.
Has anyone else experienced this?
Apple says this about cookies (on MacOS, but it’s equally valid on iOS)
(It’s a pop up on this page)
So it’s a bit arbitrary and hard to predict which cookies get ejected after a week, but a test/dev setup (raw iPs etc.) probably looks rather sketchy to the AI. If users regularly return, and the cookies are first-party, this shouldn’t happen.
I can't login to Stackdriver from the Google Cloud Console because of a login page redirect loop.
Here is the complete http request flow:
I can't provide you here the http request flow as stackoverflow said it looks like spam.
https://pastebin.com/im24CCnn
Request 3 and 9 are the login page of Stackdriver if presents me with ony the stackdriver logo and a single link with the text Log in with Google.
I've tried to restart the browser (Firefox) and clearing all caches and site data, with no change in behavior.
After some investigation, I figured out various causes for this case:
-1-
According to the documentation,
Stackdriver Monitoring relies on cookies from various Google sites to
manage Workspaces. If these cookies are blocked, you may find that you
get stuck in an endless authentication loop. Cookies can be blocked
accidentally, or by automatic updates pushed out as part of changes in
security policy at your location.
Solution:
-You must have third-party cookies enabled for the following:
google.com
accounts.google.com
apis.google.com
-Thus, after having cleared and enabled your browser cookies, make sure that they are not blocked, as for example by any extension like PrivacyBadger.
-2-
If you are logged into the browser with more than 1 account, it may cause a redirection behavior.
Solution:
-Try logging in from “Incognito mode”, or even a different browser to configure if the issue persists.
-Disable all your extensions and try again.
-3-
An update from the browser might interfere with the logging process in your browser.
Solution(same as the 2nd):
-Try logging in from “Incognito mode”, or even a different browser to configure if the issue persists.
-4-
If the version of the installed Stackdriver build is on Beta, then you might get this issue.
Solution:
-Uninstall Beta version and install a non-beta version of Stackdriver.
-5-
If nothing of the above works, please change your network and/or device and try again.
Additionally, during my research I came across few Feature Requests regarding the “Stackdriver Redirection Loop Issue”.
1-Allow the use of Google Cloud products without having cross-site tracking enabled.
2-Login loop attempting to access Stackdriver by using default settings of Firefox.
As soon as we can determine the cause, you can “star” the corresponding(one or more) Feature Request, so that it gets more visibility and also you may attach your email on the CC field, in order to get notified on any updates of the FR.
Clarification questions:
Were you able to login successfully to Stackdriver Monitoring before this issue occurred?
My company's website (mercury.co) sends password reset links via email to users. We ran into some really weird behavior that we can only reproduce in the Gmail iOS app relating to the SameSite Lax attribute:
The user follows a link in their email to https://mercury.co/reset-password
The browser loads Javascript from that URL to set up the site
The client does a GET request, which returns a CSRF token in a cookie. This token has the SameSite Lax attribute set.
Expected behavior: The client can read the cookie with the CSRF token in it. Actual behavior: The client cannot read the cookie. We've determined this by doing an alert(document.cookie) and seeing the CSRF token is not there when same-site lax is set, but is there when the same-site attribute is not set.
This causes the next POST request to fail because it can't get the CSRF token to be sent to the server. Though, if you look at the cookies that are sent in the request, it includes the cookie that has the CSRF token in it.
My understanding is that the cookie should be readable, because it is not cross-site in this context. And it certainly should not be unreadable, and then sent to the server on the next request.
My understanding is that SameSite Lax cookies should not prevent the client from reading this cookie.
As a fix, we've determined we don't need the SameSite Lax attribute on this particular cookie. However, we'd still like to understand the underlying cause of this issue.
Some details our investigation so far:
We can only reproduce the issue in the iOS Gmail app. We can't reproduce the issue by creating our own UIWebview or WKWebview (I ran in the iOS simulator for iOS 12.2). We can't reproduce it on the two iPads we tested on (though those are maybe different iOS versions). I tested on my iPhone running iOS 12.2
Based on using this method: https://stackoverflow.com/a/18678703/1176156 our application is not embedded in an iframe or anything when run in Gmail. We also disallow wrapping our site in an iframe via header.
You mostly answered your own question (and pointed me in the right direction :-) ).
For the sake of completeness, I found the relevant bug: Safari (still) doesn't send Lax cookies after a cross-site redirection.
This was fixed in release 77, which explains why the bug does not occur in iOS 12.3.1.
As it turns out, this must have been a bug in iOS 12.2, because I can no longer reproduce this behavior in iOS 12.3.1. I can't find an iOS changelog detailed enough to show this fix, though, and I didn't find anything relevant in the Webkit changelog.
I am using .Net core for backend, and authenticating users using cookies. My ionic application is working perfectly fine on android, where cookies are returned on login and are set automatically and being used for every request.
Trying it out on iOS, the cookies work fine as long as the app has not been closed (meaning both cookies sent from the server are being returned with every request).
If the app is closed and then restarted, I notice only one cookie being sent with the requests. This behavior is very weird since one cookie is being saved and is persistent throughout app restarts, in opposition to the other cookie that is no longer available after the restart. Does anyone have the slightest idea of what might be causing this?
Again, the same code was used for both platforms, and no manual handling for the cookies is being done.
I am unable to open Google, Youtube, some other website in my browser. Its showing a Certificate authentication error.
I changed it as a trusted website. Now it showing like:
(Index of /[ICO] Name Last modified Size Description)
I have no idea what to do. I am unable to google.
Other websites like facebook, yahoo and Gmail load correctly in the browser.
This is the message in google-chrome:
Your connection is not private
Attackers might be trying to steal your information from
www.google.co.in (for example, passwords, messages, or
credit cards). NET::ERR_CERT_AUTHORITY_INVALID
The Message I am getting in chrome when I click advanced:
Hide Copy Code
www.google.co.in normally uses encryption to protect your
information. When Chrome tried to connect to www.google.co.in
this time, the website sent back unusual and incorrect
credentials. Either an attacker is trying to pretend
to be www.google.co.in, or a Wi-Fi sign-in screen has
interrupted the connection. Your information is still secure
because Chrome stopped the connection before any data was
exchanged.
You cannot visit www.google.co.in right now because the
website uses HSTS. Network errors and attacks are
usually temporary, so this page will probably work later.
Is this a problem with google servers, something in between or the client side browser? Is there a workaround for this error?
This is a Chrome issues. Switch to a different browser and you will be fine. Google has decided to make getting to sites without the "expected" SSL certificate almost impossible (you can go clear the cached cert info on a site-by-site basis, which is a real pain...but expect the problem to come back again and then you have to go clear the cached cert again).
If you are using web filtering or various real security products that decrypt / inspect / then re-encrypt traffic, Chrome dumps all over it.
I used to be a Chrome fan, but because of this issue I had to abandon Chrome. I'm not going to turn off my real security products just so I can keep using Chrome!