Refactor!: auth providers

[chrismclarke]

PR Checklist

• PR title descriptive (can be used in release notes)

Breaking Changes

All auth config has been moved to a new config.auth property. Explicit reference to auth settings within the firebase config should be removed, and the previous two configuration variables to enforce login and specify the template have been merged into enforceLoginTemplate

Before	After
config.firebase = {auth: true}	config.auth = {provider: 'firebase'}
config.app_config.APP_AUTHENTICATION_DEFAULTS.enforceLogin = true	config.auth = {enforceLoginTemplate: "my_login_template"}

Both settings above would be combined as

config.auth={
  provider: 'firebase',
 enforceLoginTemplate: "example_google_auth"
}

Description

Ahead of adding support for supabase auth, refactor code to decouple firebase auth methods from main auth service

Author Notes

The breaking changes above should only impact deployments that have opted in for firebase authentication. A PR to update the debug deployment has been created at:
IDEMSInternational/app-debug-content#130

Previously the enforceLogin would only take effect on native devices (where a user is forced to login before the rest of templates displayed). Now it is also included on web to improve testability and reduce differences in experiences for user types

As far as I'm aware there's no existing documentation on working with auth actions, although if there is it would be good to also update as required

Review Notes

Update local deployment config to set auth config as per breaking changes. Will require recompile via yarn config deployment set

If enforceLogin set to true should see login screen prompt ahead of any other content. If disabled should be able to navigate as per usual and use login available within the example_google_auth sheet

Dev Notes

All handling of enforceLogin has been removed from the main app component and included within the auth service itself. In theory this means it might get triggered slightly after some other logic (depending on init orders), although testing locally it still seems to still trigger before main content loaded.

The auth code is registered in a custom auth module and included in the list of deployment-specific modules. This is currently not optimised to remove if not in use by a deployment, but could be in the future (same goes for other modules).

The auth.enabled property has been removed, in favour of assuming enabled if a provider is specified (not previously possible as multiple firebase extensions were all configured within the top-level firebase config, whereas now they use a separate config entity)

A placeholder supabase auth provider is included, however the main code will be added as a follow-up PR

If trying to test enforceLogin functionality locally all should work as expected on web, although if testing on an emulator you will need to first register your local developer debug key within the firebase console for the debug app
https://stackoverflow.com/a/52498156/5693245

Git Issues

Closes #

Screenshots/Videos

Example - native device with enforceLogin shows login screen before rest of content

untitled.webm

[jfmcquade]

Great, this paves the way nicely for using supabase as an auth provider, and it's good to see the code tidied up anyway. The functionality is working as expected for me locally.

I've added one minor query inline

[jfmcquade]

Is there a reason not to move this to the auth namespace too?

[esmeetewinkel]

Functional test passed when running locally (not tested on emulator). Happy for the signInTemplate to be moved within the auth namespace as discussed on call.

[chrismclarke]

@jfmcquade @esmeetewinkel

I've updated the PR to include the signInTemplate within the config.auth property. Given that the signInTemplate is only used when enforceLogin enabled (and given that if enforcing login a template to use is required), I've merged the two into a single enforceLoginTemplate config variable. If omitted login is not enforced, if the name of a template is provided then login is enforced and the provided template displayed.

If both are happy with the changes I think this one should be good to go.
I've also updated IDEMSInternational/app-debug-content#130 accordingly

[esmeetewinkel]

Thanks @chrismclarke. So authentication is enabled iff a provider is given, and is enforced iff a enforceLoginTemplate is given.

When login is enforced, this template is the first that shows on app launch, before the app start lifecycle events, right? I was thinking it would make sense to display a language select template first (which is currently an app start lifecycle event) but I guess I could just include a language toggle in the enforcedLoginTemplate.

[chrismclarke]

Thanks @chrismclarke. So authentication is enabled iff a provider is given, and is enforced iff a enforceLoginTemplate is given.

When login is enforced, this template is the first that shows on app launch, before the app start lifecycle events, right? I was thinking it would make sense to display a language select template first (which is currently an app start lifecycle event) but I guess I could just include a language toggle in the enforcedLoginTemplate.

That's correct, both conditions are if and only if, as we can't enable authentication without a provider and we can't enforce login unless we have a template to show. If wanting to show language select before login it might be possible to instead use launch actions to show the two templates and not use the enforceLogin feature, although could be a little awkward to only enable the close button/action if an auth user is available. So yeah I think likely better to use a custom login flow that has language select in that case

In the future it might be nice to consider exposing authoring options to limit specific templates/paths to logged in users (instead of the entire app), e.g. a user profile template, but that can be a follow-up issue as required. I guess it is currently possible to show/hide buttons that would link to specific templates with conditional @fields._app_auth_user, but could also consider an authoring option such as home_screen parameter_list auth_required: true which would display the sign_in page instead of content for those templates