Document our plugin architecture

[slifty]

The current thinking is that we will be creating two plugins:

1. A Single Sign On (SSO) plugin that allows the user to log in
2. A content (RSS) plugin that will render STAT articles based on the user's authentication status

The SSO plugin and RSS plugin will share authentication status via BuildFire's local storage tooling.

We should finalize and document this proposed architecture.

[reefdog]

Okay! After several weeks of distressingly offline work, I'm about to start sharing it.

As @slifty notes, the current architecture calls for one plugin to handle authentication with the Auth0 backend, and a second plugin to fetch and render the appropriate RSS feed. Also as mentioned, we plan to use buildfire.localStorage to locally store the user object or any authentication tokens used to verify the user's status.

While the SSO plugin will handle the user experience of negotiating with Auth0, I expect the RSS feed plugin will need a minimal amount of Auth0 interaction to verify the token it reads from buildfire.localStorage is valid and active.

We'll want to share some JS between the plugins. At the worst we'll find a way to share it here in this repo, even if each plugin is deployed with its own copy of the shared library. (I definitely don't want to bother deploying shared JS to a CDN or something.)

Keys/Secrets

Both plugins will need to be configured with some API keys that we don't want stored in the repo itself. (For SSO, these are the Auth0 domain and client ID; for RSS, these are the Plus feed credentials.)

My working design is collect those keys on the Settings section of each plugin's Control area (i.e., the area that shows up in the BuildFire admin to the app owner), then have the widget (i.e., the plugin on the user's device) fetch and use those keys.

BuildFire offers a baffling variety of datastores that could back this. I'm genuinely unsure if we want datastore, appData, or publicData. I think appData.

[reefdog]

Update: After watching the fairly anemic Creating Your First Plugin video, I better understand that datastore is the appropriate API for setting keys/secrets in the Control area, since the widget can't write to it. appData is bi-directional and would be appropriate for letting, for instance, different plugin users write to a common store accessibly by other plugin users.

[reefdog]

Looking for the right place to locally store the user token retrieved from Auth0. This will be set by the SSO plugin but read by the RSS plugin.

We'd settled on localStorage because it looked right and it worked, but we were never quite clear what this part of the docs meant, given that (again) it worked:

LocalStorage works in isolated mode for plugins so that plugin instances don't share the same localStorage.

However, upon uploading the plugins to BuildFire and testing within the app context, localStorage no longer works, so I'm now inclined to take the docs at their word: localStorage is not the right spot.

I really don't like using one of their network stores to store a local user token, so I'm going to reach out to support. I also don't know the practical differences in the various stores. Which one is most appropriate for an individual user?