-
Notifications
You must be signed in to change notification settings - Fork 915
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
WIP authIdTokenVerified #8008
base: main
Are you sure you want to change the base?
WIP authIdTokenVerified #8008
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.
|
Size Report 1Affected Products
Test Logs |
Size Analysis Report 1This report is too large (199,126 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 |
return memoizedPublicKeys; | ||
} | ||
|
||
function base64decode(base64Contents: string): string { |
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.
are there already utils for this ops? look into
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.
And if not, then add this to the util file.
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.
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.
WIP of
FirebaseServerApp.authIdTokenVerified
FYI @DellaBittaTODO: