I'm trying to write tests for authentication with Twitter and Facebook. I am using Devise and Omniauth. When I try it out it works correctly, but I can't get the tests to pass for it.
I'm following instructions, but it isn't in depth enough for me, plus I'm doing things a little differently (already have some code base). I have a custom controllers for omniauth_callbacks and registrations.
My problem is that when I run the tests it says:
(::) failed steps (::)
No route matches "/oauth/authorize" (ActionController::RoutingError)
<internal:prelude>:10:in `synchronize'
(eval):2:in `click_link'
./features/step_definitions/web_steps.rb:57:in `/^(?:|I )follow "([^"]*)"$/'
features/link_twitter.feature:19:in `And I link twitter'
Failing Scenarios:
cucumber features/link_twitter.feature:16 # Scenario: User links twitter
Where is this /oauth/authorize route coming from and how do I handle that?
It does not look like it is getting to my OmniauthCallbacksController. It follows the link and then dies. I think it has to do with Omniauth's call back method during test mode, but I'm not sure how to change / manage that.
Update: Here are my routes for Devise.
devise_for :users, :controllers => {
:omniauth_callbacks => "users/omniauth_callbacks",
:registrations => 'registrations',
:passwords => 'passwords',
:sessions => 'sessions',
:confirmations => 'confirmations'
} do
match 'confirmations/unconfirmed' => 'confirmations#unconfirmed', :as => :unconfirmed
match 'confirmations/send_advisor_confirmation/:id' => 'confirmations#unregistered_advisor_confirmation', :as => :send_advisor_confirmation
get '/users/auth/:provider' => 'users/omniauth_callbacks#passthru'
end
I forgot to put the following into env.rb
# features/support/env.rb
OmniAuth.config.test_mode = true
For more information read about the testing here.
Related
I'm working on a Rails-based API. I recently started attempting to version it. (I'm using the Versionist gem, in case it matters) One version ('v2') uses Devise and Omniauth to authenticate users through Facebook/Twitter.
I want all the routes associated with this version to have the appropriate version prefix (so users/:username/foo becomes v2/users/:username/foo, etc.), but I've already found out that putting devise_for inside the api_version block prevents the Devise helpers (current_user, user_signed_in?, etc.) from working, so it continues to live outside the block:
routes.rb:
devise_for :user, :path => '', :controllers => {:omniauth_callbacks => 'users/omniauth_callbacks'}, :skip => [:registrations, :confirmations, :sessions, :passwords]
api_version(:module => "V2", :path=>"v2") do
resources :authentications, :only => [:update, :destroy]
devise_scope :user do
post 'login' => 'sessions#create', :as => 'user_session'
get 'logout' => 'sessions#destroy'
post 'password' => 'devise/passwords#create'
put 'password' => 'devise/passwords#update'
end
end
Everything seemed great... except the Devise-generated omniauth routes:
rake routes output:
user_omniauth_authorize /auth/:provider(.:format)
user_omniauth_callback /auth/:action/callback(.:format)
Now, some google-fu revealed that there's a devise configuration setting for this, so I added the following to our devise initializer (config/initializers/devise.rb):
Devise.setup do |config|
config.omniauth_path_prefix = 'v2/auth'
end
Now, rake routes produces paths that look sensible:
user_omniauth_authorize /v2/auth/:provider(.:format) v2/users/omniauth_callbacks#passthru {:provider=>/(?!)/}
user_omniauth_callback /v2/auth/:action/callback(.:format) v2/users/omniauth_callbacks#(?-mix:(?!))
However, when I attempt to access this route by calling api.localhost/v2/auth/facebook, I get a routing error:
ActionController::RoutingError (No route matches [GET] "/v2/auth/facebook")
Any idea what's going on here?
You are missing the provider name in the routes so they don't match the facebook part in /v2/auth/facebook. The correct route destination should look something like v2/users/omniauth_callbacks#(?-mix:facebook).
Have you specified the provider in the user model?
devise_for ..., :omniauthable, :omniauth_providers => [:facebook]
For the record, I'm using Rails 3.2 and Devise 3.0 and the altered route seems to work (I haven't gone further yet to see if something else will break).
I'm trying to do something similar to Railscasts #255 but I'm getting a No Route error:
In Ryan's routes.rb file:
post "versions/:id/revert" => "versions#revert", :as => "revert_version"
In in the controller where he uses the route, versions_controller.rb
link = view_context.link_to(link_name, revert_version_path(#version.next, :redo => !params[:redo]), :method => :post)
redirect_to :back, :notice => "Undid #{#version.event}. #{link}"
In my routes.rb
post "/approve/:id" => "listings#approve", :as => "listing_approve"
and view where I use my link:
<%= link_to 'Approve Content', listing_approve_path(#listing), :method => :post %>
My tests return to me a ActionController::RoutingError: No route matches [GET] "/approve/1"
If I leave the method as a GET everything works.. Using rails 3.1.0rc5. Any guidance as to what I'm doing wrong here would be very much appreciated..
EDIT: routes.rb file (the last line is set as match right now to work)
RLR::Application.routes.draw do
root :to => "home#index"
devise_for :users, :controllers => { :registrations => "registrations" }
devise_for :users
match '/user' => "layouts#index", :as => :user_root
resources :users, :only => :show
resources :layouts, :only => [:index, :show]
resources :listings
resources :features
resources :orders
match "/preview/:id" => "listings#preview", :as => "listing_preview", :via => "get"
match "/approve/:id" => "listings#approve", :as => "listing_approve"
end
Hmmmm, it looks right to my eye. The test sounds like it is generating a GET instead of a POST though, so it might be a problem with the link_to call. You've got :method => :post there, so it should be fine. http://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html#method-i-link_to seems to indicate that link_to will generate some javascript to make a POST call on click (and that users with javascript disabled will get a normal GET link unless you use :href="#"), so it might be because your test engine isn't running the javascript.
You can fix this by changing it to a button that submits a hidden form, but that might not be the visual representation you want.
It might be a precedence thing - the first matching route definition in routes.rb is used, so if you have a resources route or something like that it may be matching on that first.
I got the same problem in my rails application and I solved it the same way you did by doing a via: :get on the match instead of a via: :post. I think for some reason when you send a request in the format of /something/:id it will automatically assume its a [GET] request and search for a get route. This of course will cause problems in your routes if you have it as a :POST.
If anyone has a better solution or idea as to why you cannot send a post request in the format '/something/:id' let me know please.
Consider this as a challenge rather than its general approach. The reason I mention this is because, it is generally preferred to incorporate admin-accessible features into the public facing site. This is what's required:
Devise model for Users, visitors accessing the public facing site
Devise model for Admins
Namespace or scope the admin 'area' to /admin. Admins can only login from this route.
Users can sign up directly from the site's public facing landing page; they are not forced to visit /users/sign_up as per the default devise generated route.
Consider overriding the default devise controllers
Thanks,
Mike.
The following seems like I've made some progress in the right direction; this at least provides identical out-of-the-box devise functionality for both users and admins, with the custom routing,
match 'admin', :controller => 'admin'
namespace :admin do
# to be updated later...
end
devise_for :users
#devise_for :admins, :path => "admin" # this works but uses the default
# Devise::SessionController
devise_for :admins,
:controllers => {
:sessions => "admin/sessions",
:passwords => "admin/passwords",
:registrations => "admin/registrations" }, :path => "admin",
:skip => [:sessions, :passwords, :registrations] do
get 'admin/sign_in' => 'admin/sessions#new', :as => :new_admin_session
post 'admin/sign_in' => 'admin/sessions#create', :as => :admin_session
get 'admin/sign_out' => 'admin/sessions#destroy', :as => :destroy_admin_session
get 'admin/sign_up' => 'admin/registrations#new', :as => :new_admin_registration
get 'admin/account' => 'admin/registrations#edit', :as => :edit_admin_registration
post 'admin/account' => 'admin/registrations#create', :as => :admin_registration
get 'admin/cancel' => 'admin/registrations#cancel', :as => :cancel_admin_registration
put 'admin/account' => 'admin/registrations#update'
delete 'admin/account' => 'admin/registrations#destroy'
post 'admin/password' => 'admin/passwords#create', :as => :admin_password
get 'admin/password/new' => 'admin/passwords#new', :as => :new_admin_password
get 'admin/password/edit' => 'admin/passwords#edit', :as => :edit_admin_password
put 'admin/password' => 'admin/passwords#update'
end
Ideas?
caveat: in this example, I've included the :registerable devise module in the Admin model just for testing during development. The sign_up route will, ultimately, be removed.
Much searching yielded (mind the pun) the following blog post that seems to indicate overriding a devise controller requires the re-mapping of all its specified 'HTTP verbs' as it were; this makes sense as unmapped ones would be handled by the default devise controller.
If anyone has more experience working with multiple devise models and the separated admin approach, I would be very much interested in your thoughts and suggestions!
This function is defined in the application_help.rb:
def gravatar_url_for(email, options = {})
url_for(
{
:protocol => 'http://',
:host => 'www.gravatar.com',
:controller => 'avatar',
# :controller => 'avatar.php',
:gravatar_id => Digest::MD5.hexdigest(email),
:only_path => false
}.merge(options)
)
end
It's used in views:
<%= image_tag(gravatar_url_for user.email, {:d => 'identicon', :s => 32, :r => 'g'}) %>
Occasionally, its usage will result in a routing error:
No route matches {:controller=>"avatar", :d=>"identicon", :r=>"g", :gravatar_id=>"486575e581db04b7c8ca218af8488657", :s=>32}
A valid email is being supplied when the error occurs.
If I replace the url_for() with this logic, it works as expected:
url_for("http://www.gravatar.com/avatar/" + Digest::MD5.hexdigest(email) + "?d=identicon&s=40&r=g")
** edit **
I had removed the following line from the routes.rb file:
# This is a legacy wild controller route that's not recommended for RESTful applications.
# Note: This route will make all actions in every controller accessible via GET requests.
match ':controller(/:action(/:id(.:format)))'
Is there a way to get the url_for to work without the 'legacy wild controller route'?
You might want to take a look at the Gravtastic plugin for Rails which supports Gravatar images in both Ruby and JavaScript.
I've added the following in my config/routes.rb file:
match 'login' => 'sessions#new'
match 'logout' => 'sessions#destroy'
match 'auth/:provider/callback' => 'sessions#create'
match 'auth/failure' => 'sessions#new'
match 'sessions/delegate' => 'sessions#delegate'
This allows me to have my own custom login form that authenticates through OmniAuth and an OpenID provider in this case. The routes and the code works well, but I have a problem with writing functional tests for the SessionsController.
Testing the new action works well:
test "show login form when requesting new session" do
get :new
assert_response :success
end
But testing the create action gives me an exception: ActionController::RoutingError: No route matches {:controller=>"sessions", :action=>"create"}
The code is like this:
test "create session adds logged in user" do
request.env['rack.auth'] = {:uid => auths(:one).open_id, :provider => 'open_id'}
post :create
# assert that create action did it's things here
end
I've tried to replace the post with a get but the result is the same.
Why is the one action found, and not the other?
Presumably it's getting confused because you're not supplying the :provider key from the match pattern. You might find it clearer to specify names for these non-resourceful routes, like:
match 'auth/:provider/callback' => 'sessions#create', as: 'callback'
This will allow you to post callback_path(provider: whatever) in your test, I think :-)