PSA: Better Firebase Authentication support for Web Extensions

[Patrick Kettner]

We are very excited to share that with this week's release of the JS SDK v10.8.0, the Firebase team has added the first Web Extensions entry point for Firebase modules!

There have recently been several threads on the mailing list about issues with some extensions using Firebase being rejected from the Chrome Web Store. These were ultimately because of remotely hosted code that was being included for Firebase Auth. Extensions are responsible for all of the code in their extension being policy compliant, regardless of who authored it. While we have been working with extension developers to fix the issue in the short term, we have also been working closely with the Firebase team to create a longer term solution. 

The new Web Extensions version of the Firebase SDK bundles all required code and avoids using remote hosted code. As of now, this is just a part of Firebase Auth. But it sets the precedent within the Firebase SDK to allow for other extension specific issues that arise to be quickly addressed through their rapid release cycles. This is not a fork of Firebase, but rather a web extension specific subset of their main API. You can use it by following along with these steps:

1. Ensure that your Firebase SDK is updated to 10.8.0

2. Where you are importing firebase/auth, use firebase/auth/web-extension instead

That's it! This will load a custom build of Firebase Auth that strips out the remotely hosted code. It is important to note that not all authentication methods are currently supported with this. If you are reliant on reCaptcha within your authentication flow, then this flavor will not work for you. There are additional complexities how reCaptcha requires it to be used that are not able to be quickly fixed here. This is not a one time update, however. We are still collaborating with the Firebase and reCaptcha team and hope to be able to get a drop in solution for all developers.

If you are a Firebase user, and see places where the SDK could be changed to better fit the nuances of the web extension ecosystem, let us know! We are really happy with the collaboration we have had with Firebase, and look forward to a lot more in the future. 

Patrick on behalf of Chrome Extensions DevRel

[Uladzimir Yankovich]

Amazing news 🥹! Thanks guys 🙏!

I hope this becomes a tradition :)

[Patrick Kettner]

Very happy to see it ship!

If you see any shortcomings with any other portion of Firebase or any other library, I would love to hear about it so we can fix it.

best

patrick

[Uladzimir Yankovich]

Of course, it would be cool to finally get stable authorization that would work out of the box without token from chrome.Identity 🥹.

[Patrick Kettner]

The release mentioned in this announcement should take care of that for you. If it doesn’t, you could email me the specifics of your set up. I will see if we can get it working more out of the box!

[Uladzimir Yankovich]

Perhaps I misunderstood you then.

I thought this release just didn't contain any removed code.

And I'm talking about the ability to use native FireBase authorization. This is currently not possible because extensions are not allowed to open a pop-up window. Historically the solution has been to get the token from chrome.identity. But our experiments show that this API is unstable and we do not want to work with it.

Or has something changed in this build and we can finally use signInWithPopup?

--

Uladzimir Yankovich,

Founder @ Manganum (manganum.app).

[Patrick Kettner]

Hi Uladzimir,

Yes, I am also talking about using native Firebase Auth. The library has been updated to change the code to support all log in flows (modulo ones that require reCaptcha). You just need to update `firebase/auth` imports to `firebase/auth/web-extension`, and it should work as expected, without using chrome.identity. That being said, I have working code samples for every type of Firebase Auth, none using chrome.identity. Feel free to reach out to me directly if you are having any questions or issues with it.

> But our experiments show that [chrome.identity] is unstable and we do not want to work with it.

What do you mean? Unstable how? Is there a bug filed about it?

patrick

[Uladzimir Yankovich]

Wow, this is very interesting. We'll try to test this next month. But we've gotten so used to server-side authentication that I'm not sure we'll be able to go back to the client-side version.

As for chrome.Identity, the fact is that there is no normal documentation for this API in offline mode. At the same time, devices often wake up without a network, and we simply lose authorization.

[Patrick Kettner]

> As for chrome.Identity, the fact is that there is no normal documentation for this API in offline mode. At the same time, devices often wake up without a network, and we simply lose authorization.

The token would persist while offline, I am not sure what situation would cause it to remove authorization. In the offline case, you a unique error "OAuth2 request failed: Connection failed (-106)". I agree we need to improve docs, but I am not seeing what you have seen here. Do you mind if I message you directly for follow up questions?

patrick

[Uladzimir Yankovich]

This was the problem. Chrome gave out a cache of tokens that had expired. Google servers returned 401. And we, on our side, could not understand what to do next and logged out the user.

Transparent documentation would help a lot.

In addition, it would be valuable to be able to explicitly tell the browser that you need a fresh token from the server.

Patrick, I'd be happy to chat - yank...@manganum.app