Is your feature request related to a problem? Please describe.
Currently, the SSR logic might throw if it's unable to verify the user's ID token. This is frustrating because it's not particularly easy for developers to catch errors in withAuthUserSSR/withAuthUserTokenSSR, and in most cases an unauthed user + optional error log is preferable to a 500 error. It would be better if the error didn't throw or was otherwise easily catchable.
361 handles more of the common Firebase errors but still throws unhandled errors.
Describe the solution you'd like and how you'd implement it
Don't throw when verifying the user's ID token server-side. Instead, return an unauthenticated user for any error, then call an optional onServerSideAuthError callback provided by the developer for the unexpected errors (ones we don't handle above).
Is this a breaking change?
Yes, a minor one, for developers that are expecting thrown errors from withAuthUserSSR or withAuthUserTokenSSR
Is your feature request related to a problem? Please describe.
Currently, the SSR logic might throw if it's unable to verify the user's ID token. This is frustrating because it's not particularly easy for developers to catch errors in
withAuthUserSSR/withAuthUserTokenSSR, and in most cases an unauthed user + optional error log is preferable to a 500 error. It would be better if the error didn't throw or was otherwise easily catchable.361 handles more of the common Firebase errors but still throws unhandled errors.
Describe the solution you'd like and how you'd implement it
Don't throw when verifying the user's ID token server-side. Instead, return an unauthenticated user for any error, then call an optional
onServerSideAuthErrorcallback provided by the developer for the unexpected errors (ones we don't handle above).Is this a breaking change?
Yes, a minor one, for developers that are expecting thrown errors from
withAuthUserSSRorwithAuthUserTokenSSRDescribe alternatives you've considered
None.