Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/crashtech/torque-admin/llms.txt

Use this file to discover all available pages before exploring further.

Torque Admin treats authentication as a first-class routing concern rather than an afterthought. Every route generated by the admin engine carries an authenticated annotation that controllers and middleware can inspect, and the engine ships with built-in support for three authentication providers so you can wire in your existing auth stack with minimal boilerplate.
Shipping an admin interface to production with authentication disabled exposes all admin data publicly. The default (default_authenticated: true) is intentionally secure. Only set default_authenticated: false in development or for fully public sections of your app.

​
The default_authenticated Setting

The default_authenticated configuration option controls the starting state of every route’s authenticated annotation: 
# config/initializers/torque_admin.rb
Torque::Admin.configure do |config|
  config.default_authenticated = true   # every route requires auth by default (recommended)
end
default_authenticated sets the baseline for all routes. Individual route blocks can override this via unauthenticated { ... } (to make specific routes public) or authenticate(...) (to set up the actual authentication mechanism).

​
Authentication Providers

Torque Admin supports three providers, defined in Mapper::Authentication::PROVIDERS: 
PROVIDERS = %i[rails custom devise]
ProviderBlock required?How it works
:railsYesYour block is evaluated inside the standard ActionDispatch::Routing::Mapper, giving you access to the Rails authenticate constraint helper.
:customYesYour block is evaluated inside the standard ActionDispatch::Routing::Mapper (via external), the same as :rails, so any standard Rails routing helpers are available.
:deviseNoAutomatically calls devise_for(resource, module: ...) via the external scope, wiring Devise’s session routes into the admin namespace.
The authenticate method is called inside your admin route definition: 
authenticate(resource, with: :provider) { ... }
When a block is provided, it is executed through the external helper, which temporarily steps out of the admin mapper’s custom scope and into a plain ActionDispatch::Routing::Mapper — this is necessary so that helpers like devise_for or Rails’ authenticate constraint work correctly.

​
Devise Authentication

Devise is the most common Rails authentication library. Use the :devise provider — no block required — and Torque Admin will call devise_for with the correct namespace automatically: 
# config/routes.rb
Rails.application.routes.draw do
  mount Admin::Engine, at: '/admin' do
    # Wire Devise session routes under the admin namespace.
    # Generates routes like /admin/users/sign_in, /admin/users/sign_out, etc.
    authenticate :user, with: :devise

    # Mark the sign-in page itself as public so unauthenticated visitors can reach it.
    unauthenticated do
      resource :session, only: [:new]
    end

    # Everything else requires the authenticated user.
    resources :posts
    resources :comments
  end
end
Internally, authenticate_with_devise calls: 
external { devise_for(resource, module: "#{admin.mod.name.underscore}/devise") }
This scopes all Devise controllers under your admin module (e.g. Admin::Devise::SessionsController), keeping them isolated from the main application’s Devise setup.

​
Rails Built-in Authentication (:rails)

Use :rails when you want to leverage Rails’ authenticate routing constraint. A block is required because Torque Admin cannot know in advance what constraint logic you need: 
# config/routes.rb
Rails.application.routes.draw do
  mount Admin::Engine, at: '/admin' do
    # Use Rails' built-in authenticate constraint — the block receives the resource.
    # The lambda receives an instance of the authenticated record.
    authenticate :user, with: :rails do
      authenticate :user, ->(u) { u.admin? }
    end

    resources :products
    resources :orders
  end
end
The block is executed inside a standard ActionDispatch::Routing::Mapper (via external), so all Rails routing helpers are available. The authenticate method inside the block is Rails’ own constraint — not Torque Admin’s.

​
Custom Authentication (:custom)

Use :custom when you have your own authentication library or a non-standard setup. A block is required, and it runs inside a standard ActionDispatch::Routing::Mapper (via external), giving you access to all standard Rails routing helpers: 
# config/routes.rb
Rails.application.routes.draw do
  mount Admin::Engine, at: '/admin' do
    authenticate :admin_user, with: :custom do
      # Any standard Rails routing is valid here.
      # For example, redirect unauthenticated visitors to a login path:
      get '/login', to: 'sessions#new', as: :login
    end

    # Protect everything else with your custom before_action in BaseController.
    resources :reports
  end
end

​
Making Routes Public: unauthenticated

Even when default_authenticated is true, you can carve out individual route groups that should be publicly accessible using the unauthenticated helper. This sets authenticated: false on all routes inside the block: 
# config/routes.rb
Rails.application.routes.draw do
  mount Admin::Engine, at: '/admin' do
    # Sign-in and password-reset pages must be public.
    unauthenticated do
      resource  :session,  only: [:new, :create, :destroy]
      resources :passwords, only: [:new, :create, :edit, :update]
    end

    # Everything below requires authentication (default_authenticated: true).
    resources :users
    resources :settings, only: [:index, :update]
  end
end

​
Auth Annotations in Controllers

Every route processed by the admin engine carries an annotations hash that includes the authenticated flag. You can read this in controllers or middleware via route_annotation(:authenticated): 
class Admin::TAController < ApplicationController
  before_action :require_authentication!

  private

    def require_authentication!
      return if !route_annotation(:authenticated)
      return if current_user&.admin?

      redirect_to admin_login_path, alert: "You must be signed in to access this area."
    end
end
The admin_application annotation is also available on every route, giving controllers a reference back to the Torque::Admin::Application instance that generated the route: 
def current_admin_app
  route_annotation(:admin_application)
end

​
Registering Authenticable Resources

When you call authenticate(resource, with: provider), Torque Admin internally calls authenticable_resource!(name, type) on the admin application to register the resource. This prevents the same resource from being registered twice: 
# Internally called — you do not invoke this directly.
admin.authenticable_resource!(:user, :devise)
If you attempt to register the same resource under two different providers, an ArgumentError is raised with a clear message. The registered resources are available via admin_application.auth_resources — a hash mapping resource name symbols to their provider type.

​
Putting It All Together

A production-ready route file combining Devise for sessions and explicit public/private scopes: 
# config/routes.rb
Rails.application.routes.draw do
  mount Admin::Engine, at: '/admin' do
    # Devise handles session routes automatically (no block needed).
    authenticate :user, with: :devise

    # Sign-in / sign-out are public.
    unauthenticated do
      resource :session, only: [:new, :create, :destroy]
    end

    # Authenticated section — the dashboard and all resources require login.
    resources :users
    resources :products
    resources :orders

    resources :settings, only: [:index, :update]
  end
end
For more on how resources, scopes, and dashboard routes work, see the Routing concepts guide.

Build docs developers (and LLMs) love

Get started for freeTalk to us