Browse Source

CLDC-724: Admin Panel requires authentication (#104)

* Admi Users must sign in to access panel

* Add ADR doc for design decision

* Add AdminUsers dashboard to ActiveAdmin
pull/107/head
Daniel Baark 3 years ago committed by GitHub
parent
commit
aa6fb32710
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
  1. 27
      app/admin/admin_users.rb
  2. 5
      app/models/admin_user.rb
  3. 4
      config/initializers/active_admin.rb
  4. 1
      config/routes.rb
  5. 18
      db/migrate/20211119120910_add_admin_users.rb
  6. 14
      db/schema.rb
  7. 1
      db/seeds.rb
  8. 9
      docs/adr/adr-010-admin-users-vs-users.md

27
app/admin/admin_users.rb

@ -0,0 +1,27 @@
ActiveAdmin.register AdminUser do
permit_params :email, :password, :password_confirmation
index do
selectable_column
id_column
column :email
column :current_sign_in_at
column :sign_in_count
column :created_at
actions
end
filter :email
filter :current_sign_in_at
filter :sign_in_count
filter :created_at
form do |f|
f.inputs do
f.input :email
f.input :password
f.input :password_confirmation
end
f.actions
end
end

5
app/models/admin_user.rb

@ -0,0 +1,5 @@
class AdminUser < ApplicationRecord
# Include default devise modules. Others available are:
# :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
devise :database_authenticatable, :recoverable, :rememberable, :validatable
end

4
config/initializers/active_admin.rb

@ -54,7 +54,7 @@ ActiveAdmin.setup do |config|
# #
# This setting changes the method which Active Admin calls # This setting changes the method which Active Admin calls
# within the application controller. # within the application controller.
# config.authentication_method = :authenticate_admin_user! config.authentication_method = :authenticate_admin_user!
# == User Authorization # == User Authorization
# #
@ -91,7 +91,7 @@ ActiveAdmin.setup do |config|
# #
# This setting changes the method which Active Admin calls # This setting changes the method which Active Admin calls
# (within the application controller) to return the currently logged in user. # (within the application controller) to return the currently logged in user.
# config.current_user_method = :current_admin_user config.current_user_method = :current_admin_user
# == Logging Out # == Logging Out
# #

1
config/routes.rb

@ -1,4 +1,5 @@
Rails.application.routes.draw do Rails.application.routes.draw do
devise_for :admin_users, ActiveAdmin::Devise.config
devise_for :users, controllers: { passwords: "users/passwords" } devise_for :users, controllers: { passwords: "users/passwords" }
devise_scope :user do devise_scope :user do
get "confirmations/reset", to: "users/passwords#reset_confirmation" get "confirmations/reset", to: "users/passwords#reset_confirmation"

18
db/migrate/20211119120910_add_admin_users.rb

@ -0,0 +1,18 @@
class AddAdminUsers < ActiveRecord::Migration[6.1]
def change
create_table :admin_users do |t|
## Database authenticatable
t.string :email, null: false, default: ""
t.string :encrypted_password, null: false, default: ""
## Recoverable
t.string :reset_password_token
t.datetime :reset_password_sent_at
## Rememberable
t.datetime :remember_created_at
t.timestamps null: false
end
end
end

14
db/schema.rb

@ -10,11 +10,21 @@
# #
# It's strongly recommended that you check this file into your version control system. # It's strongly recommended that you check this file into your version control system.
ActiveRecord::Schema.define(version: 2021_11_18_090831) do ActiveRecord::Schema.define(version: 2021_11_19_120910) do
# These are extensions that must be enabled in order to support this database # These are extensions that must be enabled in order to support this database
enable_extension "plpgsql" enable_extension "plpgsql"
create_table "admin_users", force: :cascade do |t|
t.string "email", default: "", null: false
t.string "encrypted_password", default: "", null: false
t.string "reset_password_token"
t.datetime "reset_password_sent_at"
t.datetime "remember_created_at"
t.datetime "created_at", precision: 6, null: false
t.datetime "updated_at", precision: 6, null: false
end
create_table "case_logs", force: :cascade do |t| create_table "case_logs", force: :cascade do |t|
t.integer "status", default: 0 t.integer "status", default: 0
t.datetime "created_at", precision: 6, null: false t.datetime "created_at", precision: 6, null: false
@ -88,7 +98,6 @@ ActiveRecord::Schema.define(version: 2021_11_18_090831) do
t.integer "tcharge" t.integer "tcharge"
t.integer "layear" t.integer "layear"
t.integer "lawaitlist" t.integer "lawaitlist"
t.string "property_postcode"
t.integer "reasonpref" t.integer "reasonpref"
t.string "reasonable_preference_reason" t.string "reasonable_preference_reason"
t.integer "cbl" t.integer "cbl"
@ -153,6 +162,7 @@ ActiveRecord::Schema.define(version: 2021_11_18_090831) do
t.datetime "sale_completion_date" t.datetime "sale_completion_date"
t.datetime "startdate" t.datetime "startdate"
t.integer "armedforces" t.integer "armedforces"
t.string "property_postcode"
t.index ["discarded_at"], name: "index_case_logs_on_discarded_at" t.index ["discarded_at"], name: "index_case_logs_on_discarded_at"
end end

1
db/seeds.rb

@ -7,3 +7,4 @@
# Character.create(name: 'Luke', movie: movies.first) # Character.create(name: 'Luke', movie: movies.first)
User.create!(email: "test@example.com", password: "password") User.create!(email: "test@example.com", password: "password")
AdminUser.create!(email: "admin@example.com", password: "password")

9
docs/adr/adr-010-admin-users-vs-users.md

@ -0,0 +1,9 @@
### ADR - 010: Admin Users vs Users
#### Why do we have 2 User classes, AdminUser and User?
This is modelling a real life split. `AdminUsers` are internal DLUHC users or helpdesk employees. While `Users` are external users working at data providing organisations. So local authority/housing association's "admin" users, i.e. Data Co-ordinators are a type of the User class. They have the ability to add or remove other users to or from their organisation, and to update their organisation details etc, but only through the designed UI. They do not get direct access to ActiveAdmin.
AdminUsers on the other hand get direct access to ActiveAdmin. From there they can download entire datasets (via CSV, XML, JSON), view any log from any organisation, and add or remove users of any type including other Admin users. This means TDA will likely also require more stringent authentication for them using MFA (which users will likely not require). So the class split also helps there.
A potential downside to this approach is that it does not currently allow for `AdminUsers` to sign into the application UI itself with their Admin credentials. However, we need to see if there's an actual use case for this and what it would be (since they aren't part of an organisation to be uploading data for, but could add or amend data or user or org details through ActiveAdmin anyway). If there is a strong use case for it this could be work around by either: providing them with two sets of credentials, or modifying the `authenticate_user` method to also check `AdminUser` credentials.
Loading…
Cancel
Save