content: 1.1.9

[esmeetewinkel]

Google Auth config changes following / testing PR IDEMSInternational/open-app-builder#2235

[esmeetewinkel]

@jfmcquade I believe I would need the Appetize action to test whether the Google Auth still works, can you think of any other way?

[github-actions]

Visit the preview URL for this PR (updated for commit 9ea9ec2):

https://plh-teens-tz--pr12-content-1-1-9-a492antl.web.app

_{(expires Tue, 09 Apr 2024 15:55:11 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: d0b53cec31298d9c96ba66bad5bd819dda8306ff}

[jfmcquade]

@jfmcquade I believe I would need the Appetize action to test whether the Google Auth still works, can you think of any other way?

I think you're right. I can make a local Android build (using this PR's content branch and the feat/deployment-firebase branch of the code repo) and test on an emulator, I will do so and add a review to this PR.

In terms of building to Appetize: the reusable action is available as of PR #2200 on the code repo. I will manually configure an Appetize app for this deployment, as described in my latest comment on that PR. Then all that's left is for @ChrisMarsh82 to make a deployment-level github action on this repo that calls the reusable action.

[esmeetewinkel]

@jfmcquade the private.key sits on my device locally, should I store/share that somewhere e.g. on BitWarden?

[jfmcquade]

I can confirm that the auth functionality works as expected, see demo of app running in emulation (built from this content branch and the feat/deployment-firebase branch of the main repo):

emulator.sign.in.mov

I did have to re-add the line in the config that sets the value app_config.APP_AUTHENTICATION_DEFAULTS.enforceLogin = true, see this commit. This setting is not superseded by the firebase.auth.enabled = true setting.

The difference is:

• firebase.auth.enabled = true means that the feature is initialised so that the Google sign in functionality can be called through the associated github action at runtime.
• app_config.APP_AUTHENTICATION_DEFAULTS.enforceLogin = true means that authentication is actually enforced at login, with a template that cannot be bypassed until the user has signed in (this can be set to a custom template via the APP_AUTHENTICATION_DEFAULTS.signInTemplate property, the default template name is "sign_in")

As we don't actually use the auth feature for anything other than the initial sign in on launch, we'll currently always set these two properties together, but they do accomplish different things. I think this could be made clearer, although I'm not quite sure how at this stage.

[jfmcquade]

I've added an issue to configure building to Appetize from content repos here.