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