Primary Key change - BREAKING CHANGE

This is a breaking change to any previous dev tags.

Primary key is now a UUID vs email - so now users email's can be changed (but are still kept unique).

Various other cleanups and database migration files consolidation since this was a breaking change anyway.

Typed JWT claim values

Ability to now indicate claim values in the JWT to have a JSON type (before ,everything was a string)

Now fields can be appended with /i or /b for JSON number coercion or boolean (true/false) coercion.

Example:

:user_id/i would coerce the user record 'user_id' field to number type in the JWT. 'user_id' is a varchar in the database; so this is a way to coerce that to JSON numeric format for downstream services. Likewise for /b for JSON 'true' or JSON 'false' value via Mojo::JSON->true/false.

Note this doesn't have any affect if the claim is an ARRAY ref type -- the array will be flattened to a string and any dynamic elements (e.g. :user_id/i) will just be string values like present.

Fixes non-secured default routes and fixes inline template renders

If for some reason the default route was unsecured, it would not work as expected. So now you can specify the default_route to be unsecured and behave as expected.

Also inline template renders I don't think worked as expected. Right now inline templates won't be rendering through the EPL engine but you can still render a block of raw text/html -- or you can use EPL syntax but it'll get resolved at app bootstrap via the JSONConfig plugin... not per request. The change here is to the routing syntax, e.g. template_name => "inline: <b>Text Here</>" whereas omitting the inline: prefix will make the app look for an actual template file of that name.

No more inline evals

Got rid of that feature left from early days... more restrictive for things like JWT claim value resolutions and the transforms, but safer. Effects change to the json config file as well -- see updated WIKI.

EDIT: bumping to 0.2.3 to match the Dockerfile push version (long story).

Route spec consolidation and logging

Route consolidation via the config file using the 'additional_paths' key within a route spec .. which should be a JSON array of additional path strings to match for given spec. Before you had to duplicate the info for every route spec if you wanted multiple paths to be routed to a particular target.

MOJO_DEBUG_LEVEL=info now in Dockerfile to show the proxying lifecycle messages (delete if you don't want).

Landing Page Setting

defines new landing_page setting option... to allow specification to a route to redirect to when we're just logging in.

Release v0.1.0 - User Account Lockout

adds the user account lock-out-after-X-attempts (if the "max_login_attempts" config key is present and set. Also adds ability on the UI for an admin to lockout/unlock accounts manually.

Deciding to bump to 0.1.0 minor since seems to be more stable with each new feature and testing coverage has increased as well.

With MFA (2FA) support

With opt-in MFA (2FA) support.

Set mfa_secret, mfa_issuer, mfa_key_id in app config, and check user's Is MFA option on UI and users will be forced to enroll into 2FA on next login (by scanning QR code into something like Google Authenticator).

Optionally you can force the whole userbase into it by setting the mfa_force_on_all to true to force everyone to enroll on next logon.

DB usage for AuthZ

Mainly just does db hits now for authZ (just caches email in the session cookie for AuthN). So that changes can be realized quicker if need be without having to rotate secrets or something.

With Audit Log Feature

Adds Audit logging of inbound requests (and its result). This is added to the admin SPA UI. These are also searchable/filterable via that UI. To enable logging - in the app's .json file, add the enable_logging: true key/value pair. You can also add logging_ignore_paths: [ "/some-paths/to/ignore", "/another/path" ] to ignore and not log requests to that path.