README.md in nulogy_sso-2.1.1 vs README.md in nulogy_sso-2.1.2

- old
+ new

@@ -63,21 +63,21 @@ # Compiles config/auth_sso.yml into a Ruby object. An error is thrown if required keys are missing. # See lib/nulogy_sso.rb for required keys. NulogySSO.sso_config = Rails::Application.config_for(:sso) # Return the user matching the provided email, or nil if not found. -NulogySSO.find_user_by_email = ->(email) { nil } +NulogySSO.find_user_by_email = ->(email) { nil } # Handle errors from the SSO authentication flow, according to the app's design. # This includes internal errors from the Auth0 gem (ie, token signature mismatch) and no user from the app DB matching the email from the JWT. # The controller is passed as an argument to give the handler access to the "controller context", which is useful for tasks such as rendering a view. NulogySSO.handle_sso_error = ->(controller: , error:) { } # Handle how unauthenticated requests should be responded to. The default is to redirect to the defined login page. # For API based applications this should be overriden to provide a meaningful error as per your API's contract (i.e. an HTTP 401 error code) -# Additionally, this could be overriden if an application should bypass SSO when running tests. -NulogySSO.handle_unauthenticated_request = ->(controller) { controller.redirect_to sso_engine.login_path } +# Additionally, this could be overriden if an application should bypass SSO when running tests. +NulogySSO.handle_unauthenticated_request = ->(controller) { controller.redirect_to sso_engine.login_path } ``` The app is now ready to authenticate a user with Auth0! With NulogySSO and Auth0, the user's identity is maintained across requests (and apps!) via a [JWT](https://auth0.com/docs/jwt) stored as a browser cookie. Add this code to the `ApplicationController`: ```ruby @@ -107,22 +107,16 @@ docker-compose up -d ``` ### Testing +Tests must be run manually before submitting a PR. This can be done using `rspec spec`. + There are multiple helpers made available via the `NulogySSO::TestUtilities` module. These are helpful for doing things such as grabbing test JWT values and interacting with a [Mockserver](https://github.com/jamesdbloom/mockserver) mock of the Auth0 API. -It is a common use case for a Rails app to switch from Devise-powered authentication to Auth0. Here's a pattern that could be applied around a feature flag (e.g. environment variable) to switch between Devise user authentication test helpers and NulogySSO test helpers: _(TODO: insert link to CPI `ControllerIntegrationSpecMacros`)_ +It is a common use case for a Rails app to switch from Devise-powered authentication to Auth0. This would also require updates to test helper code, similar to [functionality that Devise provides out of the box](https://github.com/heartcombo/devise/wiki/How-To:-Test-controllers-with-Rails-(and-RSpec)). [See this example](https://github.com/nulogy/Common-Platform-Interface/blob/f9444ded80d6012b9659942481fa2e6b880b54ee/spec/support/controller_integration_spec_macros.rb) of how a test helper could be written for an app using a feature flag (e.g. environment variable) to switch between Devise and NulogySSO authentication. ### Contributing Feel free to create a PR if you wish to add new functionality to this Engine or detect a bug. A developer on CN1 will review and merge. This project follows [Semver Versioning](https://semver.org/). Please add an entry into [CHANGELOG.md](./CHANGELOG.md) in your PR. Deployments are done manually on an as-needed basis. - -## Roadmap - -* Parameterize app name for error page -* Buildkite pipeline -* Rubocop -* Rake install task (ie, generate required files automatically, instead of requiring a heavy amount of manual work to integrate nulogy_sso into a Rails app) -* Add additional hooks, as necessitated by unique use cases for new apps using this engine