|
1 |
| -[Aeacus - The holder of keys](https://en.wikipedia.org/wiki/Aeacus) |
| 1 | +[Echo - ECHO Echo echo...](https://en.wikipedia.org/wiki/Echo_(mythology)) |
2 | 2 | ======
|
3 | 3 |
|
4 |
| -A simple, secure, and highly configurable Elixir identity [username | email | id | etc.]/password authentication module to use with Ecto. |
| 4 | +A simple & highly extendable, meta-notification system; Echo checks notification preferences & dispatch notifications to different adapters (ex. email, logger, analytics, sms, etc.). |
5 | 5 |
|
6 |
| -[](https://travis-ci.org/zmoshansky/aeacus) [](https://hex.pm/packages/aeacus) [](https://hex.pm/packages/aeacus) [](https://github.com/zmoshansky/aeacus/issues) [](https://github.com/zmoshansky/aeacus/pulls) |
| 6 | +[](https://travis-ci.org/zmoshansky/echo) [](https://hex.pm/packages/echo) [](https://hex.pm/packages/echo) [](https://github.com/zmoshansky/echo/issues) [](https://github.com/zmoshansky/echo/pulls) |
7 | 7 |
|
8 | 8 | #### Description ####
|
9 |
| -Aeacus only performs authentication, making it well suited for integration with session storage, or a token system; like [Guardian](https://github.com/hassox/guardian). Alternatively, this could be used directly over a secure (HTTPS) connection with [HTTP Basic Auth](https://en.wikipedia.org/wiki/Basic_access_authentication); But, it is highly discouraged as there is a greater security risk, due to repeatedly sending your authentication information to the server, only relying on TLS for security. |
10 |
| - |
11 |
| -#### Requirements #### |
12 |
| -Aeacus requires that you have an Ecto model that has UNIQUE(identity_field) and password_field. These fields can be configured to easily match your schema, whether it be `username`, `email`, or `pass`, `password`, `hash`, `hashed_password`, etc. Of course, the passwords must be stored using the same crypto system as Aeacus; The password should be salted and hashed, plaintext is heavily discouraged. See the tests for examples. |
| 9 | +Echo is designed to be highly adaptable to your notification needs through different adapters and per adapter hooks. A notification is dispatched with `Echo.notify/2` which then calls on each registered adapter, requesting that it delivers the notification. Each adapter is passed an `event_type`, of your designation, and `data` that it may use to deliver the notification. |
13 | 10 |
|
14 | 11 | #### Config ####
|
15 |
| -You must set the `:repo` and `:model` for Aeacus. The other options have sane defaults. |
| 12 | +Echo is easible configured, a possible sample configuration is given below. Custom Preferences & Adapters are easy to build, look at `lib/echo/adapters/email` & `test/support/test_preferences.ex` for examples. Hooks allow you to specify the module which implements `@behaviour Echo.Hooks`, which generates the adapter specific data needed to deliver a notification (see `test/support/email_hook` for an example); this might include: selecting the correct template, parsing data, or even nothing at all. Doing nothing allows unknown event types to be skipped by adapters. |
16 | 13 |
|
17 | 14 | ```
|
18 |
| -config :aeacus, Aeacus, |
19 |
| - repo: MyApp.Repo, |
20 |
| - model: MyApp.User, |
21 |
| - # Optional, The following are the default options |
22 |
| - crypto: Comeonin.Pbkdf2, |
23 |
| - identity_field: :email, |
24 |
| - password_field: :hashed_password, |
25 |
| - error_message: "Invalid identity or password." |
| 15 | +config :echo, Echo, |
| 16 | + preferences: Echo.Preferences.AllowAll, |
| 17 | + adapters: [Echo.Adapters.Logger, Echo.Adapters.Email, YourApp.CustomAdapter], |
| 18 | + hooks: %{ |
| 19 | + email: YourApp.EmailHook |
| 20 | + } |
26 | 21 | ```
|
27 | 22 |
|
28 |
| -#### Example Session Controller #### |
29 |
| -`Aeacus.Authenticator.authenticate` expects a `Map` with keys `:identity`, and `:password`. Alternatively, `Aeacus.Authenticator.authenticate_resource` can be used if a resource is already loaded. |
| 23 | +#### Architecture #### |
| 24 | +Echo is somewhat like a pub-sub system; events are published, and adapters that are capable of handling them dispatch the notification accordingly. The intended flow is: |
| 25 | + |
| 26 | +- `preferences` module provides an ACL to check whether an event should be delivered on a particular adapter according to a user's preferences (ex. deny newsletters, but allow billing emails). |
| 27 | +- `hooks` provide a way to prepare arguments to an adapter based on the `event_type` & `data`. A hook can prevent it's adapter from delivering the notification if no data is returned. This means notifications are only sent for adapters that are configured to handle them, otherwise, they are harmlessly disregarded by that adapter. |
30 | 28 |
|
| 29 | +ex.) In the code below, an email is sent for `:user_register`, but not `:log_analytics`; `Adapter.Email` will harmlessly skip it as an `:unknown_event`. |
| 30 | +``` |
| 31 | +Echo.notify(:log_analytics, data) |
| 32 | +... |
| 33 | +Echo.notify(:user_register, data) |
31 | 34 | ```
|
32 |
| -defmodule MyApp.SessionController do |
33 |
| - def create(conn, params) do |
34 |
| - case Aeacus.Authenticator.authenticate %{identity: params[:email], password: params[:pass]} do |
35 |
| - {:ok, user} -> CreateTokenOrCookie |
36 |
| - {:error, message} -> DisplayAuthenticationScreenAgain |
| 35 | +``` |
| 36 | +defmodule App.EmailHook |
| 37 | +@behaviour Echo.Hooks |
| 38 | +
|
| 39 | + def message(event_type, data) do |
| 40 | + ... |
| 41 | + template = case event_type do |
| 42 | + :user_register -> "emails/register.html.eex" |
| 43 | + :user_forgot_password -> "emails/forgot_password.html.eex" |
| 44 | + _ -> nil |
37 | 45 | end
|
| 46 | + ... |
38 | 47 | end
|
39 | 48 | end
|
40 |
| -``` |
| 49 | +``` |
0 commit comments