Can we make authentication check more robust?

[joelanman]

We recently saw a prototype without authentication. It's possible this is down to the check here requiring "production" - which is set on Heroku but may not be set on other hosts. Is there a more bulletproof check to ensure authentication is on when deployed to any server?

[nataliecarey]

What we'd like to do in response to this finding:

• Identify why it didn't work in this case, try to include this use case to help other users - recognising there's another environment to support and supporting it
• Allow the user to set a FORCE_AUTH parameter so the user can override what we detect - recognising we won't always know about all environments so gibing the user more control
• Switch the logic to detect a dev environment making production the default (note: do we need a different start script e.g. npm run dev)

[joelanman]

this has come up again - Azure has no default NODE_ENV so authentication is not activated

[lfdebrux]

I was thinking the other day (for an unrelated issue about dev dependencies and Glitch) that really we should have two npm scripts, dev and serve, that run the appropriate script (and possibly set the appropriate NODE_ENV at the same time). That would act as a small bit of documentation for users as to what to use where, as well as making a Procfile / app config easier.

[joelanman]

this is higher priority now we're even less sure where people are hosting, though we have added NODE_ENV=production to the publish docs

[lfdebrux]

We've agreed for v13 to make the common default npm command, npm start, run the kit in 'production' mode. This is a breaking change, but makes it much less likely that users will end up with unsecured prototypes in production.

[Izabela-16]

@joelanman to provide outcome conversation he had with Natalie. Documentation will need an update as well.

[lfdebrux]

Okay, v13 will now use the npm run dev command for local development, solving this issue.