I have a problem with the devise gem, I have this controller.
class AdminController < ApplicationController
before_action :authenticate_user!
def index
end
def per
end
def po
end
end
When redirect to sign_in form , shows nothing
sign_in form
These are my routes:
match 'po' => 'admin#po', :via => :get
match 'per' => 'admin#per', :via => :get
match 'admin' => 'admin#index', :via => :get
match 'admin/index' => 'admin#index', :via => :get
match 'admin/per' => 'admin#per', :via => :get
match 'admin/po' => 'admin#po', :via => :get
devise_for :users, :controllers => { :omniauth_callbacks => "callbacks" }
root 'home#index'
I have three templates: application, admin and home
I overwrite the default route after log in
class ApplicationController < ActionController::Base
# Prevent CSRF attacks by raising an exception.
# For APIs, you may want to use :null_session instead.
protect_from_forgery with: :exception
#before_action :authenticate_user!
def after_sign_in_path_for(resource)
#request.env['omniauth.origin'] || stored_location_for(resource) || admin_path
admin_path
end
end
My last gem installed:
gem 'bootstrap-sass'
You need to run the generator for Devise views which will copy the necessary files in your views folder:
Run:
rails g devise:views
There is more information on configuring the Devise views here
Your problem probably isn't with Devise, it looks systemic to me.
#config/routes.rb
namespace :admin do
root "application#index" #->
resources :model_controller, path: "", only: :index do #-> url.com/admin/...
collection do
get :po #-> you shouldn't really have this
get :per #-> you shouldn't really have this
end
end
end
devise_for :users, :controllers => { :omniauth_callbacks => "callbacks" }
This will give you the following:
#app/controllers/admin/application_controller.rb
class Admin::ApplicationController < ApplicationController
before_action :authenticate_user!
def index
# do something here
end
end
This gives you the ability to create a custom "dashboard" type page for your admin area, from which you'll be able to use controllers bound to models.
Your po and per actions really shouldn't be there - they are not part of the CRUD system
In regards to your Devise views, the other answers are correct in that you would be best to generate the Devise views in your app:
rails generate devise:views
This won't solve your problem (hence why I downvoted the other answers). It will simply put the views in your app. It will do nothing apart from put code in a different place.
You will need to debug the issue:
Check the action you're seeing at /users/sign_in
Check the code in the <body> tags (which you haven't shown)
If the HTML is there, there will be some other issue preventing it from loading
If there is no HTML, it will likely mean a problem with the core of Devise
What I would recommend you do is the following:
Generate your views
From your screenshot, show us the contents of the <body> tag
Screenshot your console log (this will show any errors)
Update your question with the above
This will give you a much clearer perspective on what the potential issue will be, and allow other community members to better define the solution.
I'm overriding the default Devise signin method as such:
def after_sign_in_path_for(resource)
stored_location_for(resource) || jobs_path
end
So that when an authenticated users signs in, they are taken to my jobs page. Which is fine,
but the problem I'm having is that I'd like to be able to utilize the Devise password (new/edit) pages, typically found at /users/password/new and /users/password/edit but when I attempt to go to those locations (http://localhost:3000/users/password/new), I get immediately redirected back to jobs page. What do I need to do to correct this. Below is part of my routes.rb if that helps:
devise_for :users, :skip => [:sessions] do
# devise/sessions
get 'signin' => 'devise/sessions#new', :as => :new_user_session
post 'signin' => 'devise/sessions#create', :as => :user_session
get 'signout' => 'devise/sessions#destroy', :as => :destroy_user_session
end
resources :users
Thanks in advance for your time and assistance.
The devise wiki says that users can edit their password using the registerable module:
https://github.com/plataformatec/devise/wiki/How-To:-Allow-users-to-edit-their-password
Have you tried just using devises methods for letting users change their password?
Also, here is a related question:
Rendering the Devise edit Password Form
I am using omniauth and found devise using a subfolder for this(in official example) controllers/users/omniauth_callbacks_controller.rb. I need to create a User show page as well as other actions for User so I decide to create a new UsersController inside a controllers/users folder. Now it looks like
class Users::UsersController < ApplicationController
def show
#user = User.find(params[:id])
end
end
routes.rb
My::Application.routes.draw do
devise_for :users, :controllers => { :omniauth_callbacks => "users/omniauth_callbacks" }
match 'users/:id' => 'users/users#show'
root :to => 'home#index'
end
it works but the route created is unnamed
rake routes gives
/users/:id(.:format) users/users#show
without GET and route_name
so I'm unable to use it for example after login redirect. Is there a better way to realize the subfolder routes structure and is it good idea to group controllers like this?
You just need name your route in your route.rb
match 'users/:id' => 'users/users#show', :as => 'user'
After that you can call this route by user_url(user.id)
See example on guides : http://guides.rubyonrails.org/routing.html#naming-routes
devise_for creates routes including a DELETE route, which we want to remove, and devise_for doesn't support an :except or :only option.
How can I remove a route from Rails.application.routes? Either in the draw block, or afterward?
Here are details of a bug, which was the reason we needed to remove the route.
we were issuing a DELETE request to a custom UJS controller action
in the controller action we were removing what we wanted to, then doing a 302 redirect. This was a bad idea, and we have since corrected it by returning some JSON instead.
some clients, upon receiving the 302 would issue a new DELETE request to the redirect, which routes to a Devise delete route! Thereby inadvertantly deleting the person! Yikes. We were assuming this would be a GET. Bad assumption.
This bug has been fixed, but i would like to remove the route nonetheless.
Here is what I did in the end, which was suggested by the bounty-winner in his quote from Jose´ Valim:
In config/routes.rb, I added this above the devise_for call, which sets up the rest of my 'people' routes:
delete '/person', :to => 'people#destroy'
Then in my existing people_controller.rb, I added a no-op method:
def destroy
render :nothing => true
end
I'm still a little irked that there isn't a simple way to just remove the route from the RouteSet. Also, the delete route still exists for the devise controller, but it won't get called because rails looks for the first match in config/routes.rb and returns it.
Here is what Jose Valim (the author of devise) has to say on the subject:
There is no way to remove routes individually. Or you use :skip to
remove all and draw the ones you need manually or you overwrite this
routes by defining a route to the same path first in your config/
routes.rb
So the short answer to your question is no, you can't delete that one route. You can of course try doing things like patching the devise_for method, but that would be a somewhat involved undertaking (a day or several worth of effort). I'd just use the :skip option, then implement the routes you do want for that controller and leave off the one that you don't.
Yes, kinda. You can completely overwrite devise controllers used and write your own (inheriting Devise's if needed). This wiki page can serve as guideline.
Edit
Why I have said kinda :)
Overriding sessions using:
devise_for :users, :controllers => { :sessions => 'custom_devise/sessions'}, :skip => [:sessions] do
get 'sign_in' => 'custom_devise/sessions#new', :as => :new_user_session
post 'sign_in' => 'custom_devise/sessions#create', :as => :user_session
end
will give you only two routes [:get, :post], but not :destroy
new_user_session GET /sign_in(.:format) {:controller=>"custom_devise/sessions", :action=>"new"}
user_session POST /sign_in(.:format) {:controller=>"custom_devise/sessions", :action=>"create"}
So, effectively, you skip destroy/delete route. Now in controller you can go:
class SessionsController < Devise::SessionsController
def new
super
end
def create
super
end
end
You can now repeat the process for registrations, passwords and unlocks.
Second Edit
Ah, yes there is another, simpler way. You can manually create routes (documentation) using devise_scope also known as "as" without overriding:
as :user do
get "sign_in", :to => "devise/sessions#new"
post "sign_in", :to => "devise/sessions#create"
...
end
Gives:
sign_in GET /sign_in(.:format) {:controller=>"devise/sessions", :action=>"new"}
POST /sign_in(.:format) {:controller=>"devise/sessions", :action=>"create"}
Third Edit
Also, you could overwrite part of Devise in charge of creating these routes, (only to be used in applications that will have no devise "destroy" route whatsoever), by creating an initializer:
module ActionDispatch::Routing
extend ActionDispatch::Routing
class Mapper
protected
def devise_session(mapping, controllers) #:nodoc:
resource :session, :only => [], :controller => controllers[:sessions], :path => "" do
get :new, :path => mapping.path_names[:sign_in], :as => "new"
post :create, :path => mapping.path_names[:sign_in]
end
end
def devise_registration(mapping, controllers) #:nodoc:
path_names = {
:new => mapping.path_names[:sign_up],
:cancel => mapping.path_names[:cancel]
}
resource :registration, :only => [:new, :create, :edit, :update], :path => mapping.path_names[:registration],
:path_names => path_names, :controller => controllers[:registrations] do
get :cancel
end
end
end
end
Note that this fix removes all destroy routes used in Devise (there are only two in "sessions" and "registrations") and is a fix only for this specific case.
In addition
You could also add :except option to routes. In order to do it, you must add devise_for method (copy it from original and modify to suit your wishes) to Mapper class so it sends [:except] member of options to above-mentioned (in code) private methods.. Then you should modify those to add routes based on conditions.
Fastest, dirty way, would be to add #scope[:except] = options[:except] and then to modify private methods so that except hash (if you decide to have fine grained route control like: :except => {:sessions => [:destroy]}, thus making :skip obsolete) or array (if you want to remove this specific action from all routes, like: :except => [:destroy]) is checked before adding route.
Anyway, there are plenty ways to achieve what you need. It's up to you to pick the one you think is best suited.
Actually devise_for does support :skip and :only, for example (docs):
devise_for :user, :skip => :registration
This will skip all the registration controller's routes, rather than one specifically. You could then implement the routes you need. This seems cleaner than removing the route after the fact.
UPDATE:
Another possible solution is to use Rails' advanced constraints feature to block the unwanted route completely:
# config/routes.rb
constraints lambda {|req| req.url =~ /users/ && req.delete? ? false : true} do
devise_for :users
end
Here is a post on using lambdas for route constraints. The request object is explained here. This might be the simplest solution.
I found a simple solution with Devise 4.2.0 and Rails 5.0.1. I think this will work with Rails 4, and I'm uncertain about older versions of Devise.
Create an initializer overriding the devise_* route helpers. Examples methods are devise_session, devise_password, devise_confirmation, devise_unlock, and devise_registration. Check out the source.
Ensure the initializer is loaded after the Devise initializer by giving the filename a larger alphanumeric value.
For example, Devise creates a :confirmation route with the :new, :create, and :show actions. I only want the :create action.
# config/initializers/devise_harden.rb
module ActionDispatch::Routing
class Mapper
# Override devise's confirmation route setup, as we want to limit it to :create
def devise_confirmation(mapping, controllers)
resource :confirmation, only: [:create],
path: mapping.path_names[:confirmation], controller: controllers[:confirmations]
end
end
end
Now POST /auth/confirmation is the only route setup for confirmation.
I have successfully added the ability to use dynamic subdomains within my application. The issue is that when I run my Cucumber tests, I receive the following error when my application performs a redirect_to which contains a subdomain:
features/step_definitions/web_steps.rb:27
the scheme http does not accept registry part: test_url.example.com (or bad hostname?)
I have a signup controller action that creates the user and the account chosen and redirects the the user to the logout method with the subdomain specified based on what the user selected as the subdomain in the sign up form. Here is the code for the redirect action that happens once the user and account models are created and saved:
redirect_to :controller => "sessions", :action => "destroy", :subdomain => #account.site_address
Here are my rails 3 routes:
constraints(Subdomain) do
resources :sessions
match 'login', :to => 'sessions#new', :as => :login
match 'logout', :to => 'sessions#destroy', :as => :logout
match '/' => 'accounts#show'
end
Here is the code I have so far for the Subdomain class which is specified in the constraint above:
class Subdomain
def self.matches?(request)
request.subdomain.present? && request.subdomain != "www"
end
end
I added UrlHelper to the ApplicationController:
class ApplicationController < ActionController::Base
include UrlHelper
protect_from_forgery
end
This is the code for the above UrlHelper class:
module UrlHelper
def with_subdomain(subdomain)
subdomain = (subdomain || "")
subdomain += "." unless subdomain.empty?
[subdomain, request.domain, request.port_string].join
end
def url_for(options = nil)
if options.kind_of?(Hash) && options.has_key?(:subdomain)
options[:host] = with_subdomain(options.delete(:subdomain))
end
super
end
end
All of this code above allows me to run subdomains fine within the local browser. The issue above happens when I run my Cucumber test. The test clicks the signup button which in turn calls the redirect_to and throws the exception listed above.
Here is what my gem file looks like:
require 'subdomain'
SomeApp::Application.routes.draw do
resources :accounts, :only => [:new, :create]
match 'signup', :to => 'accounts#new'
constraints(Subdomain) do
resources :sessions
match 'login', :to => 'sessions#new', :as => :login
match 'logout', :to => 'sessions#destroy', :as => :logout
match '/' => 'accounts#show'
end
end
Could you please let be know an additional method to have my tests work now? I would be interested in either a fix or a way I can test my methods without using subdomains (for example a mocked out method that retrieves the account name).
I have this same pattern in my code. I use Capybara (but not Cucumber), and I was able to get around it like this:
# user creates an account that will have a new subdomain
click_button "Get Started"
host! "testyco.myapp.com"
# user is now visiting app on new subdomain
visit "/register/get_started/" + Resetkey.first.resetkey
assert_contain("Get Started Guide")
The host! command effectively changes the host as it appears to the app from the test request.
EDIT: Just realized this was working with webrat, but not capybara (i'm using both, phasing out webrat now.) The way I'm doing it in capybara is to either click a link to a new domain (capybara follows it) or to:
visit "http://testyco.myapp.com/register"
EDIT: Another update. Found a method that works without having to use the full URL in every event.
host! "test.hiringthing.com"
Capybara.app_host = "http://test.hiringthing.com"
In the test setup.