Authenticate with nmdc-server backend

[pkalita-lbl]

Fixes microbiomedata/issues#561

These changes rely on the changes from microbiomedata/nmdc-server#1130. I'm keeping this in draft until those changes are merged and I can test authentication against the dev nmdc-server instance.

New dependencies

@capacitor/browser is added in order to open a browser window to initiate the login process.

Making authenticated API requests

The src/api.ts module has been refactored a bit to support making API requests using a bearer token in the Authorization header. Previously this module exported individual, stateless request-making functions. However we now have a bit of stateful-ness: sometimes the application will have an API token and sometimes it will not depending on your login state.

I chose to reimplmenent this as sort of a object-oriented singleton pattern. There is a base FetchClient class which wraps calls to fetch and knows how to provide the bearer token if you give it one. The NmdcServerClient inherits from FetchClient and defines methods to request specific endpoints. One instance of NmdcServerClient is created and exported by the module. The state of this single instance can be updated (by calling the setBearerToken method) as login or logout events happen.

Application data store

The src/Store.tsx module sets up a new React context that can be used to get and set (possibly in persistent storage) arbitrary application data. For now it's just holding the API token string. It also provides access to the underlying persistent storage object. It exports a StoreProvider component and a hook to access the context value.

When the StoreProvider component is initialized, it sets up the persistent Storage object and checks to see if there is an API token there. If it finds one it uses that value to update its in-memory state (in order to rerender anything that depends on it) and the NmdcServerClient singleton instance. The same things happen when calling the exported setApiToken function, plus updating the value in persistent storage.

Query provider updates

Previously the TanStack Query provider was set up along with the persistent storage object in src/App.tsx. This has been refactored into a separate component (src/QueryClientProvider.tsx). Instead of setting up a Storage object itself, this component makes use of the useStore hook exported by src/Store.tsx to get the Storage object it needs for persisting API data.

With the new StoreProvider and QueryClientProvider components, I also took the opportunity to move the routing setup into a separate Routes component (src/Routes.tsx). This allows src/App.tsx to be radically simplified.

New routes

First there is a new Route wrapper component called AuthRoute (src/components/AuthRoute/AuthRoute.tsx) which uses the useStore hook to access the API token. If it is null it redirects the user to a new /login route, otherwise it renders just like a normal Route. This is based on ideas from https://v5.reactrouter.com/web/example/auth-workflow. We're using react-router v5 because Ionic doesn't support v6 yet (ionic-team/ionic-framework#24177).

The new /login route displays src/pages/LoginPage/LoginPage.tsx which is a very un-pretty page directing the user to login along with a button to initiate the login process.

When the login process completes, nmdc-server will link back into the /token route. The src/pages/TokenPage/TokenPage.tsx page simply extracts the token from the redirect URL, uses setApiToken provided by useStore, and redirects the user to the /home route. The /home route is now protected as an AuthRoute.

Finally the /logout route displays src/pages/LogoutPage/LogoutPage.tsx which uses setApiToken provided by useStore to clear the API token and redirect back to the root route.

[eecavanna]

I haven't looked at the diff yet, but I have read the PR description and thought that was great! 👏

[yxu-lanl]

Thanks.

[eecavanna]

Looks great! Thanks for implementing this and for documenting it so clearly and thoroughly.