-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ServerApp] Firebase Server App feature branch #8005
Conversation
Baseline addition of the FirebaseServerApp object.
…IdToken (#7944) Add support for logging-in users with the FirebaseServerApp's authIdToken. ### Testing Local project testing client-side created users, passing idTokens to serverApps, and logging in the user. Tested with multiple users and multiple instances of FirebaseServerApps w/ Auth. CI tests (added integration tests). ### API Changes N/A
…ck later (#7989) Removed the appCheck and installations token parameters in FirebaseServerAppSettings as they won't be part of our initial launch. Additionally, update the the doxgen comments to no longer refer to these parameters, and to inform users that the User refreshToken will not work for User objects signed in with the authIdToken.
Mangle the name of the ServerAap based on the hash of the parameters passed in. In addition, return the same instance of app when the same parameters are used.
Update the `FirebaseServerApp` creation to return the same object if an existing object exists with the same configuration. However, the `deleteOnDeref` field is ignored when detecting duplicate apps, since that object reference could vary across multiple SSR rendering passes. The hope is that a `FirebaseServerApp` instance awaiting deletion from a the `deleteOnDeref` feature maybe be reused if another SSR pass occurs in rapid succession, there by speeding up the SSR code.
🦋 Changeset detectedLatest commit: db24403 The changes in this PR will be included in the next version bump. This PR includes changesets to release 5 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Changeset File Check ✅
|
Size Report 1Affected Products
Test Logs |
Size Analysis Report 1This report is too large (448,338 characters) to be displayed here in a GitHub comment. Please use the below link to see the full report on Google Cloud Storage.Test Logs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for Auth team. Thanks!
Updates FirebaseServerApp implementation in Auth to prevent operations that would change the currently logged in user. The user should be that of the authIdToken provided to FirebaseServerApp only. Note: some of the method implementations currently reside in browser-only files. I added safe guards to these methods even though FirebaseServerApp is not supported in browser enviornments. These guards protect us in case the methods are later adapted to other environments and/or migrated to other files that are not browser-only. The changes to the browser implementations produce little overhead, so I thought that safety first was the correct call here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some things to look at David, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more things to look at David, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Text strings LGTM, thanks!
let auth: Auth; | ||
|
||
beforeEach(() => { | ||
auth = getTestInstance(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this default instance ever used or are all the tests run on a getTestInstanceForServerApp() instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the tests use this auth instance to create a new user (through varying means) and then uses that newly created user's idToken to initialize FirebaseServerApp.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two small matters I raised in comments, otherwise LGTM
It turns out the FirebaseServerApp implementation in #8005 was not blocking auth initialization, so when testing end-to-end we were seeing race conditions with auth state. In this PR I address by awaiting the user fetch and moving the implementation into AuthImpl#initializeCurrentUser for cleanliness.
We're rethinking how authIDTokenVerified should be used. It might reside in its own function. Remove the method for now.
Add a new serverapp string so that register version to track FirebaseServerApp usage.
Discussion
Feature branch for the addition of FirebaseServerApp - a tool to ease the use of working with Firebase in SSR frameworks.
Testing
New CI tests in Auth and App, including unit and integration tests.
API Changes
API proposal approved.