A how to (i.e. step by step guide) on setting up admin accounts would be great for newbies?

[christobh]

Hi janko & community,

I'm pretty new to rails - so I understand its not a problem for the very skilled.
The documentation is really comprehensive, however, I am completely confused after trying to setup admin accounts (i.e. Multiple configurations) using the available documentation.

My previous app used Devise and luckily there were a lot of external blogs / threads etc that helped me get the features I needed.

For the app I am working on currently, I was excited to use rodauth-rails due to all the builtin multi-factor auth functionality.

My goal is to have admin accounts, as a means to access sensitive data or app functionality.

Here are the Steps I followed and where I ultimately got stuck?:
Note I get especially confused as to how I am supposed to setup routes...

STEP 1:

The generated rodauth_app.rb file has commented sections for an admin configuration, so I uncommented these:

  configure(:admin) do
    # ... enable features ...
    prefix "/admin"
    session_key_prefix "admin_"
    # remember_cookie_key "_admin_remember" # if using remember feature
  
    # search views in `app/views/admin/rodauth` directory
    rails_controller { Admin::RodauthController }
  end

 r.on "admin" do
      r.rodauth(:admin)
    
      unless rodauth(:admin).logged_in?
        rodauth(:admin).require_http_basic_auth
      end
    
      break # allow the Rails app to handle other "/admin/*" requests
    end

STEP 2:

I added the admin controller:

# app/controllers/admin/rodauth_controller.rb
class Admin::RodauthController < ApplicationController
end

STEP 3:

I add :admin to the account.rb model:

class Account < ApplicationRecord
  include Rodauth::Rails.model(:admin)
end

Question, should I just replace Rodauth::Rails.model with Rodauth::Rails.model(:admin) above? Does that mean I need two seperate account models? One for normal users and one for admin users? I would like to use the same model for both?

STEP 4:

I add the migration for account types:

# db/migrate/*_create_account_types.rb
class CreateAccountTypes < ActiveRecord::Migration
  def change
    create_table :account_types do |t|
      t.references :account, foreign_key: { on_delete: :cascade }, null: false
      t.string :type, null: false
    end
  end
end

I then run the migration and manually set one of my existing accounts to be of type admin in the db (using dbeaver)

STEP 5:

I set a page I would like only an admin user to access:

  constraints Rodauth::Rails.authenticated(:admin) do
    resources :performance_dashboards
  end

This causes the following routing error: No route matches [GET] "/admin/login"

I tried many things, one of which was to set 'r.rodauth(:admin)' just under r.rodauth based on what I could gather from the docs:

 r.rodauth         # route primary rodauth requests
 r.rodauth(:admin) # route secondary rodauth requests

None of this worked?

I gathered from this that I would also have to generate new views for these routes using
rails generate rodauth:views -all --name admin ?

But this is not really what I want, I am happy to just set a user as an admin on the backend and have them login via the existing original routes? i.e. /login NOT /admin/login. Not sure if that's even possible?

STEP 6:

I also tried using the following:

constraints Rodauth::Rails.authenticated { |rodauth| rodauth.rails_account.admin? } do
  resources :performance_dashboards
end

But receive this error:
undefined method `rails_account' for #<#Class:0x00007feb2855ee00:0x00007feb28576028 @scope=#<RodauthApp::Middleware request=#<RodauthApp::Middleware::RodaRequest GET /performance_dashboards> response=#<RodauthApp::Middleware::RodaResponse nil {} []>>>

I have no idea if I should / how to make use of the below while still using only the configs for :admin in rodauth_app.rb (i.e. Single-file configuration):

# app/misc/rodauth_main.rb
class RodauthMain < Rodauth::Rails::Auth
  configure do
    # ...
    rails_account_model Authentication::Account # custom model name
  end
end

As you can see - just all over confusion on how to approach the setup?
Think a step by step guide or a demo app with both a normal user account and an admin account setup could go a long way with helping rails beginner's like me move over from Devise to Rodauth-rails...

But any guidance as to the above would be greatly appreciated by anyone in the meantime?

Best & thanks!

[janko]

I agree a guide would be useful. I will first see about adding an admin account to the demo app, then see about writing a guide (though I would appreciate help with the guide).

OK, I see you tried combining code form different sources, including some from older code comments. I will try to answer your questions below.

STEP 1:

The generated rodauth_app.rb file has commented sections for an admin configuration, so I uncommented these:

This is a good start, though the routing logic assumes that you enabled the http_basic_auth feature. You only need r.rodauth(:admin) call for routing all admin routes, nothing else is needed anymore, but make sure you're using the latest rodauth-rails version.

route do |r|
  r.rodauth
  r.rodauth(:admin) # routes admin routes
end

STEP 2:

I added the admin controller:

Yes, that's necessary 👍🏻

STEP 3:

I add :admin to the account.rb model:

This depends, how much common/differing authentication features that require database tables will main & admin configurations use? If one will be a superset of the other one, feel free to include the model mixin only for that one. But if main configuration uses verify_account and remember, and admin configuration uses verify_account and otp, then neither Rodauth configuration can generate all associations combined. Maybe it would make sense to support some kind of merging of association definitions, I will explore that.

STEP 4:

I add the migration for account types:

This should also be followed up with configuration changes shown in that wiki page.

STEP 5:

I set a page I would like only an admin user to access:
[...]
This causes the following routing error: No route matches [GET] "/admin/login"

You haven't enabled the login feature in the admin configuration, so that route doesn't exist. Rodauth will only define routes for features you've enabled.

But this is not really what I want, I am happy to just set a user as an admin on the backend and have them login via the existing original routes? i.e. /login NOT /admin/login. Not sure if that's even possible?

Then you should remove the prefix "/admin" from the admin configuration. But then your main configuration will route those routes, not admin. What should differ then between admin and regular account in terms of authentication? Do you even need a separate Rodauth configuration?

STEP 6:

I also tried using the following:
[...]
But receive this error:
undefined method `rails_account' for #<#Class:0x00007feb2855ee00:0x00007feb28576028 https://github.com/scope=#<RodauthApp::Middleware request=#<RodauthApp::Middleware::RodaRequest GET /performance_dashboards> response=#<RodauthApp::Middleware::RodaResponse nil {} []>>>

Are you using the latest rodauth-rails version?

I have no idea if I should / how to make use of the below while still using only the configs for :admin in rodauth_app.rb (i.e. Single-file configuration):

# app/misc/rodauth_main.rb
class RodauthMain < Rodauth::Rails::Auth
  configure do
    # ...
    rails_account_model Authentication::Account # custom model name
  end
end

This isn't related to multiple configurations, this is when you're using a model name that cannot be inferred from the table name (defaults to :accounts).

As you can see - just all over confusion on how to approach the setup?

I recommend starting the admin configuration to be exactly the same as the main configuration, and then go from there. The easiest way to do that is using inheritance, by defining a base class, where you copy all current main configuration, and then defining main & admin subclasses of that base class which start out empty. Then gradually decide in what way admin authentication should differ.

# app/misc/rodauth_base.rb
class RodauthBase < Rodauth::Rails::Auth
  configure do
    # copy the whole main configuration here
  end
end

# app/misc/rodauth_main.rb
class RodauthMain < RodauthBase
  configure do
    # empty
  end
end

# app/misc/rodauth_admin.rb
class RodauthAdmin < RodauthBase
  configure do
    # empty
  end
end

class RodauthApp < Rodauth::Rails::App
  configure RodauthMain
  configure RodauthAdmin, :admin

  route do |r|
    r.rodauth
    r.rodauth(:admin)
  end
end

[christobh]

@janko
Thanks so much for the quick reply
I was definitely not using the latest version which was the cause for a lot of my confusion - my mistake.
I've started as you suggested and I think I am on the right track
When I get through this I'd be happy to write something up for the community.

I seem to be getting somewhere,
but I do have an issue with the new changes in the accounts table when using 1.3.0.. I think..
In my app, accounts are referenced to a few other models.

Problem is the that the new migration conflicts with the old migration:

rails generate rodauth:install
Running via Spring preloader in process 79106
    conflict  db/migrate/20220412010003_create_rodauth.rb
Another migration is already named create_rodauth: /home/x/code/x/db/migrate/20211213094036_create_rodauth.rb. Use --force to replace this migration or --skip to ignore conflicted file.

Question 1,
Is there a simple way to upgrade the db for the table changes from to v1.3.0, without affecting existing references to account_id?
Is the correct way to change the original 20211213094036_create_rodauth.rb migration to the new one by just changing the file content..?
(for now I got it working like that)

Question 2,
If I sign up as admin, and then login should I not have the current_account(:admin) method available?
I get this error when trying to call it:

[8] pry(#<PostsController>)> current_account(:admin)
  Sequel (1.0ms)  SELECT * FROM "accounts" INNER JOIN "account_types" ON ("account_types"."account_id" = "accounts"."id") WHERE (("id" = 4) AND ("type" = 'admin') AND (("status" = 2) OR (("status" = 1) AND ("id" IN (SELECT "id" FROM "account_verification_keys" WHERE ((CAST("requested_at" AS timestamp) + CAST('86400 seconds ' AS interval)) > CURRENT_TIMESTAMP)))))) LIMIT 1
  ↳ (pry):11:in `index'
Sequel::DatabaseError: PG::AmbiguousColumn: ERROR:  column reference "id" is ambiguous
LINE 1: ...nt_types"."account_id" = "accounts"."id") WHERE (("id" = 4) ...
                                                             ^

from /home/x/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/rack-mini-profiler-2.3.4/lib/patches/db/pg.rb:113:in `exec'
Caused by PG::AmbiguousColumn: ERROR:  column reference "id" is ambiguous
LINE 1: ...nt_types"."account_id" = "accounts"."id") WHERE (("id" = 4) ...
                                                             ^

from /home/x/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/rack-mini-profiler-2.3.4/lib/patches/db/pg.rb:113:in `exec'

Calling just current_account gives:

[10] pry(#)> current_account
ArgumentError: invalid account id passed to account_ds
from /home/cbh/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/rodauth-2.22.0/lib/rodauth/features/base.rb:683:in `account_ds'

Question 3, What also confuses me is why is a non-admin account able to sign in through admin/login and /login? (for now, I am replicating the same auth process) How do I prevent this, such that only an admin can sign in via admin/login and a normal user only through /login?

In this case I am using the same accounts table with a sub table for roles as per https://github.com/janko/rodauth-rails/wiki/Account-Types

[janko]

Question 1,
Is there a simple way to upgrade the db for the table changes from to v1.3.0, without affecting existing references to account_id?

There is no need to do anything other than updating the gem. There were some changes in the generated configuration and migration (e.g. storing password hash in the accounts table), but unless you really need them, I'd suggest to leave it like it is for now.

Question 2,
If I sign up as admin, and then login should I not have the current_account(:admin) method available?
I get this error when trying to call it:

Yeah, it seems like recent changes in how Rodauth account is retrieved is conflicting with account types query, do to not using qualified column names. Does it work when you use a subselect instead of a join?

    auth_class_eval do
      def account_ds(*)
        super.where(id: db[:account_types].where(type: "admin").select(:id))
      end
    end

Calling just current_account gives:

[10] pry(#)> current_account
ArgumentError: invalid account id passed to account_ds
from /home/cbh/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/rodauth-2.22.0/lib/rodauth/features/base.rb:683:in `account_ds'

Really not sure where this is coming from. Could you post a full backtrace?

Question 3, What also confuses me is why is a non-admin account able to sign in through admin/login and /login? (for now, I am replicating the same auth process) How do I prevent this, such that only an admin can sign in via admin/login and a normal user only through /login?

That's a fair point, I overlooked that when writing the wiki page, since I haven't yet used multiple account types. The easiest way to fix that would probably be exclude admins when fetching the account in the main configuration:

# app/misc/rodauth_main.rb
class RodauthMain < Rodauth::Rails::Auth
  configure
    # ...
  end

  private

  def account_ds(*)
    super.exclude(id: db[:account_types].where(type: "admin").select(:id))
  end
end

It would probably be good to come up with a generalized override that would live in the base superclass, which would apply to all configurations. I think I will generalize this to "roles" instead of "account types", so that it's also usable for authorization.

[christobh]

Hi @janko

Thanks again for the help!

RE: Q2, changing to a subselect seems to just force a logout when I call current_account(:admin),

pry(#<PostsController>)> current_account(:admin)
  Sequel (2.3ms)  SELECT * FROM "accounts" WHERE (("id" = 4) AND ("id" IN (SELECT "id" FROM "account_types" WHERE ("type" = 'admin'))) AND (("status" = 2) OR (("status" = 1) AND ("id" IN (SELECT "id" FROM "account_verification_keys" WHERE ((CAST("requested_at" AS timestamp) + CAST('86400 seconds ' AS interval)) > CURRENT_TIMESTAMP)))))) LIMIT 1
  ↳ (pry):8:in `index'
Redirected to /admin/login
Completed 401 Unauthorized in 2017ms (ActiveRecord: 2.3ms | Allocations: 15687)

So stuck, if you have any other thoughts? I think if I can just get current_accounts(:admin) working I might have a working solution for now.

RE: "Really not sure where this is coming from. Could you post a full backtrace?"

I think we can ignore that? I was calling current_account while in an admin session.. which I assume I should not be doing. But from what I can see its a similar error to the above with regards to the account_ds(*) quesry... Hope that makes sense.

[janko]

RE: Q2, changing to a subselect seems to just force a logout when I call current_account(:admin)

It's hard to say without knowing the current state of your Rodauth configuration. Are you still setting a session prefix for admins? That's important, otherwise the logged in state clashes with main configuration. Maybe you didn't complete account verification, and the 24-hour verify grace period expired? 🤷🏻‍♂️

[benkoshy]

There's a video documenting this: https://www.youtube.com/watch?v=N6z7AtKSpNI