Closed opolo closed 1 year ago
@opolo which sign in method and provider are you using? We are aware that popup-based signs in particular require localStorage and will not work when it is disabled. As a potential workaround you can try signing directly with the provider (Google, Facebook, etc) using their SDK and then signing into Firebase using signInWithCredential().
Hey @opolo. We need more information to resolve this issue but there hasn't been an update in 5 weekdays. I'm marking the issue as stale and if there are no new updates in the next 5 days I will close it automatically.
If you have more information that will help us get to the bottom of this, just add a comment!
I just started getting this error with Google Chrome 83 today, trying to sign in via a Google account while in Incognito mode.
Just updated to Chrome Version 83.0.4103.61 (Official Build) (64-bit) Our firebase auth integration no longer appears to work..investigating. This is not in incognito mode.
Still works with Chrome Canary Version 85.0.4157.4 (Official Build) canary (64-bit), Firebox, and Safari.
Update: Clearing Site Data instantly allowed Firebase Auth UI to appear correctly. Not sure of the specific cause. Sorry for the issue noise. Cheers.
@avolkovi it was one of our users that faced this issue; I do not believe I can get the information again. Perhaps the comments by @brianmhunt or @tmcf helps.
Also getting this error after upgrading to Chrome 83.0.4103.61 (OSX).
Also getting this issue after updating to Chrome 83. It had been working consistently in incognito mode before that. Same error message as @brianmhunt
{
"code": "auth/web-storage-unsupported",
"message": "This browser is not supported or 3rd party cookies and data may be disabled."
}
Also getting this issue after updating to Chrome 83. It had been working consistently in incognito mode before that. Same error message as @brianmhunt
{ "code": "auth/web-storage-unsupported", "message": "This browser is not supported or 3rd party cookies and data may be disabled." }
Same problem with my app. It happens in incognito mode randomly and for some users it is consistent.
This is happening to my app - https://app.zenuml.com . For myself, it is consistent on Chrome - Version 83.0.4103.106 (Official Build) (64-bit). Haven't heard anything from our users.
It works fine on Chrome Canary Version 85.0.4175.0 (Official Build) canary (64-bit). So I am not sure if it is the browser's issue or not.
Sorry, I think this may have been closed by mistake. Re-opening.
If you change the Chrome browser cookie settings from the default value of "Block third-party cookies in Incognito" to "Allow all cookies", Google authentication then succeeds in Chrome incognito:
(Not that this should be a work-around, of course -- just as additional information for the issue.)
Note also that once all cookies have been allowed, authentication then triggers console warnings regarding a missing 'SameSite' attribute:
I'm also having this issue only in Chrome in Incognito:
Happy to provide more info to debug if needed.
Any solutions?? I am facing the same issues
Any solutions?? I am facing the same issues
I am facing the same issue intermittently. But, if I login using this sample app - https://fir-ui-demo-84a6c.firebaseapp.com/ and try logging in my app, it seems to work. You can use this as a workaround, if it is happens occasionally.
Any solutions?? I am facing the same issues
I am facing the same issue intermittently. But, if I login using this sample app - https://fir-ui-demo-84a6c.firebaseapp.com/ and try logging in my app, it seems to work. You can use this as a workaround, if it is happens occasionally.
I am able to login normally but not in incognito mode
I deleted my previous comment. I will try to give this issue more light
chrome://settings/cookies?search=allow+all
Allow All Cookies !
(Repeating my previous comment that changing the client browser settings to "allow all" -- or per the comment of @curiouscod3 -- is NOT an acceptable work-around. We cannot expect our users to make this kind of change in their browsers.)
I have 10K users of my application. @curiouscod3 are you suggesting that I should ask all my users to do that changes in there browser seriously????
tracking internally via b/161150773
I have the same issue. "@angular/fire": "^6.0.2" GoogleAuthProvider signInWithRedirect incognito mode
This issue is recent, any updates ?
Folks-
To provide a small update, we are looking at ways internally to mitigate this, some notes for now:
1) This issue is due to chrome blocking our use of local persistence within an iframe in incognito, though we understand that this behavior may become default even in non-incognito in the future.
2) Unfortunately this breaks our implementation of the popup & redirect flows, fixing this issue will require a major rethink of how we perform these flows, including updating server side logic. We're also going to look to see if there are short term fixes we can implement.
Workarounds for now: 1) As mentioned above (https://github.com/firebase/firebase-js-sdk/issues/3004#issuecomment-647007598), on the client side your customers can opt-out of this new behavior, this is obviously not ideal (https://github.com/firebase/firebase-js-sdk/issues/3004#issuecomment-655764893)
2) Until we have a long term fix, you can update your app to perform a "manual" OAuth Flow (example for Google sign-in) by using signInWithCredential if you need to support Chrome Incognito.
@jesselve Of Course, I mentioned it for the test/dev purpose because I was developing apps in that mode couldn't proceed anymore without the setting option.. I am also annoying with it.. I agree It should work without allow *** all :)
Attempted work around #2 (use Google sign-in), but does not appear to work in Firebase Incognito mode.
GAPI gives an error on page load: details: "Cookies are not enabled in current environment." error: "idpiframe_initialization_failed"
Opening google sign in pop up window works, but doesn't trigger the data-onsuccess callback when sign in is complete. It works fine outside of incognito mode (and also when third party cookies are enabled).
@avolkovi Same issue here. The second workaround of using a "manual" OAuth Flow also does not work, as it seems GAPI also needs cookie access, returning:
details: "Cookies are not enabled in current environment." error: "idpiframe_initialization_failed"
Hoping the team will find a solution soon.
Isn't this also something which should be breaking with newest Safari? https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ Is it breaking there as well? If not, why not and what are Chrome and Safari doing differently?
For those landing on this page from Google, you might want to check https://github.com/firebase/firebase-js-sdk/issues/865#issuecomment-394324472
Although it seems unrelated at first, I realized the issue was happening because of a "cross domain" cookie. Incognito mode in Chrome by default block cross domain cookies, not all of them.
This was happening because I was using the default firebase callback url https://auth-xxxx.firebaseapp.com/__/auth/handler
When registering my own url on the same domain as my website, it worked well even in incognito mode!
@vicdup For your method to work, the site has to be hosted with Firebase hosting right? I don't think one can do the same trick if the site is hosted somewhere else.
As mentioned here https://github.com/firebase/firebase-js-sdk/issues/2241#issuecomment-658924408 firebase auth is being rewritten from the ground up. So, could we expect a fix in the new version?
@HellBlazer616 We are working on providing fixes both in the new version and also back-porting the changes to the current version.
Update on longer term fixes: We should have a fix for the popup flow soon, the redirect flow will take longer as it requires a more complicated solution.
Thanks for the update @avolkovi ! Looking forward to the changes 😄 Do update us here when it's up!
Hi folks, Hope this can help. It is an alternative solution that was being used in my company's project.
To make the app working again, you have to create a new custom AUTH URL with the DOMAIN which you are using.
In other words, The Domain of the new auth URL must equivalent to the Domain of your current web app.
That can solve all the problems including the sameSite
issue.
So how to change the auto-provision auth URL of firebase? All steps were listed in the document. See Customizing the redirect domain for Google sign-in
I was inspired by this post This browser is not supported or 3rd party cookies and data may be disabled. Thanks @bpetetot
You may have already noticed this but we had already fixed the popup flow for browsers with 3P cookies disabled. You should be able to use it without updating the SDK. As for the redirect flow, it is still a work in progress. For now, you may have to fallback on the popup flow for browsers with 3P cookies disabled.
@bojeil-google We have implemented workaround 2 mentioned here and are still experiencing issues with the idpiframe_initialization_failed
error being thrown on load. The Google account selection pop-up shows up but the data-onsuccess
callback when sign in is complete is not thrown.
Is there another workaround you recommend before biting the bullet and implementing server-side Auth 2.0 flow?
@avolkovi could you confirm if updating the custom domain of cookie will fix the auth flow when 3rd party cookie is disabled? even if project is not using firebase hosting? Just want to make sure before investing time in custom domain implementation.
@sam-gc can you provide our latest guidance?
@GorvGoyl we don't actually use cookies, it's just that the machinery that blocks third-party cookies in incognito also prevents certain features that we do make use of. What fix are you specifically looking at? Incognito mode should now work for signInWithPopup
.
@sam-gc thanks for the clarification on cookies part. I was actually using signInWithRedirect
(Firebase: ^8.9.1) which was causing auth issue. signInWithPopup
is working fine in incognito mode.
Hi, for everyone that experienced this problem, just switch on the third pqrty cookies fornthe incognito sesssion and this will be resolved. :D
I think that a workaround for this problem is to use signInWithPopup
only when in incognito mode on Chrome, and signInWithRedirect
when not in incognito mode. There is a way to us make the same test that firebase SDK makes to throws auth/web-storage-unsupported
, for select the way of our users will do google login ? I don't found a easy solution looking in the firebase source code
On the blank incognito page, there is a slider for 3rd party cookies. You should enable third party cookies in irder for the firebase auth to work.
I think that a workaround for this problem is to use
signInWithPopup
only when in incognito mode on Chrome, andsignInWithRedirect
when not in incognito mode. There is a way to us make the same test that firebase SDK makes to throwsauth/web-storage-unsupported
, for select the way of our users will do google login ? I don't found a easy solution looking in the firebase source code
Yeah that would be great. I've tried detecting incognito mode for this exact reason, but this is not as easy as it looks: turns out incognito is made with the aim of not being easily detectable itself. Being able to directly test the firebase functionality that throws an error on incognito sure would be an ideal solution. Let us know if you find something @igorsilveriocosta !
@andrewhamili We can not ask our users to do that
@joel-moonlight this is not a restriction 9f the firebase but a restriction of the browser. I think it is on google chrome only. I do not know on other browsers if they are also disabling 3rd party cookies on browser mode similar to incognito of google chrome.
I think there is no fix or workaround that the firebase team can offer.
PS: I haven't tried if using signInWithPopup might do some trick as advised by @igorsilveriocosta
I haven't tried if using signInWithPopup might do some trick as advised by @igorsilveriocosta
It does, hence our messages.
@joel-moonlight well thats good. But i think signInwithPopup won't work with webviews. It odes not work on in-app browser of Messenger App.
That's why we want to use it only when signInWithRedirect
won't work, hence our messages.
As I can verify in my own environment this issue still exists... Is there any idea on how to solve this and is there a timeline for it? It might be good to include a note about this behaviour in the firebase documentation becuase this issue now exists nearly 3 years...
As I can verify in my own environment this issue still exists... Is there any idea on how to solve this and is there a timeline for it? It might be good to include a note about this behaviour in the firebase documentation becuase this issue now exists nearly 3 years...
The options listed in https://firebase.google.com/docs/auth/web/redirect-best-practices apply to this issue as well.
Closing since it is a duplicate of https://github.com/firebase/firebase-js-sdk/issues/6716
[REQUIRED] Describe your environment
[REQUIRED] Describe the problem
Multiple of our users has reported, they are no longer able to login and use our product... After some investigation, it seems to happen for all the users, which accesses our platform in incognito mode.
It seems to no longer be possible to use the firebase auth SDK in Google Incognito mode. The exact same users can log in with the exact same credentials or SSO integrations through firebase in non-incognito.
Steps to reproduce:
If users try to use firebase authentication on our platform in incognito mode, the error:
{code: "auth/web-storage-unsupported", message: "This browser is not supported or 3rd party cookies and data may be disabled.", a: null}
is thrown from the SDK.I believe it potentially can be an issue in a newer Chrome update, as I know Google has been experimenting with having Chrome block 3rd Party Cookies (I believe they experimented with it in version 83 of Chrome, which I am not using though).