I have done a redirection to dashboard_path after user signing in.. I believe that there should be an action called dashboard in that controller. But when I removed that dashboard action in the controller it still worked fine. How is it possible.? Please help. I am confused.
In the sessions controller
def create
admin=Admin.find_by_email(params[:session][:email].downcase)
user=User.find_by_email(params[:session][:email].downcase)
if user && user.authenticate(params[:session][:password])
redirect_to dashboard_path
else
redirect_to(admins_index_path(:current_admin=>admin))
end
end
In the User controller (If I removed this action in user controller still it redirects to dashboard page.. how??)
def dashboard
end
routes.rb
match '/dashboard' => 'admins/users#dashboard'
It's called 'convention over configuration', and Rails have a lot of it. If you don't specify any render or redirect_to in the controller action, Rail's default behavior is to redirect to the view with the same name as the action.
You should read the Action Controller Overview for more information on this subject (it's part of the Rails guides and contains a lot of information on Rails behavior).
Related
I have an issue when i am loging in to site after clicking on other menu tabs it is automatically loging out and if i wait for few minutes refresh and then login tabs are working fine.If i logout and login again and i click on other tabs geting loged out. I am not understanding where i need to check the code.
class SessionsController < Devise::SessionsController
# POST /resource/sign_in
def create
respond_to do |format|
format.json do
self.resource = warden.authenticate!(auth_options)
sign_in(resource_name, resource)
return render :json => resource
end
format.html do
super
end
end
end
end
I think issue it related to your authenticity_token
If you make a links in menu with the help of Rails form helper then You will not face this issue
I changed the default in controller
protect_from_forgery with: :exception
to
protect_from_forgery with: :null_session
will also solve problem in rails 4
I was having this problem trying to render a partial via an asynchronous request from my users views.
The problem was that CanCan was not authorizing the call, because it was inside a new action that I created on user_controller.rb. I am new to Rails and I thought that putting :edit on the ability class was enough.
I caught this error because I removed the remote: true from my link, so it can render the view via a http request. Don't as me why I did that. Begginer's luck!
My question is: how could I have debugged that error if not by luck?
You could have added test cases that accounted for the rendering of that partial, for instance (with rspec):
response.should render_template(:partial => 'partial_name')
I am running a sinatra app and have a testing suite setup using rspec 2.7.0 and webrat 0.7.3 (both the most recent versions). I have an extensive set of tests for all of my request actions and it seems to be working fine. Today I discovered Sinatra's redirect back request-level helper and implemented it in a couple of areas of my application that were rendering forms with get requests which were taking parameters.
The nice thing about the redirect back helper is that if I have an action say:
get '/login' do
#used_var = params[:var]
haml :login
end
Which renders a form, I can have validation on the post request receiving the form:
post '/login' do
# pretend User.authenticate pulls back a user entry from the database if there
# is a valid username/password combination
unless User.authenticate(params[:username], params[:password]).nil?
redirect '/content'
else
flash[:notice] = "Invalid username/password combo"
redirect back # will redirect back to the get '/login' request
end
end
And if the form doesn't validate properly, it will redirect back to the page with the from and retain any parameters that were passed in without me having to worry about storing it to a session variable. The only problem is that rspec doesn't seem to want to play nicely with the redirect back helper. i.e. if I have a spec action that does this:
it 'should redirect to login when invalid username/password combo is received.' do
get '/login', :var => 'value'
fill_in 'username', :with => 'invalid_username'
fill_in 'password', :with => 'invalid_password'
click_button 'Submit'
last_response.should be_redirect; follow_redirect!
last_request.url.should include("/login")
end
The spec fails to pass because for some reason it seems that rspec or webrat isn't picking up on the redirect back helper and is instead redirecting the request back to the root url for my application ('/').
What I want to know is whether there is a way to get rspec to redirect to the proper location in these instances? The actual application functions as expected when I test it with my browser (it redirects me to the first page with parameters), but the rspec tests don't pass properly.
try to pass :referer => '/login' to your requests, so redirect_back can know where the actually 'back' is
Apparently this was a bug in rack, and it appears to have been fixed with the release of rack 1.3.0. I tested this spec with rack 1.2.5 (most recent version prior to 1.3.0 release), and it failed, but upon upgrading to 1.3, it started passing.
After some digging around, pretty sure that this pull request (here is the commit) was the change that fixed it.
So it is no longer an issue in rack ~> 1.3.
I'm new at cucumber and capybara so maybe this is easy.
I'm using headers to check if a user is logged in or not and i'm having a problem when doing cucumber testing.
I use Capybara and Cucumber and a "add headers hack": http://aflatter.de/2010/06/testing-headers-and-ssl-with-cucumber-and-capybara/
The problem I have is that it only sets the header once in each feature story. So if I have a story that goes trough more than one step the header is gone and the user is no longer logged in.
An example story:
Given I am logged in as a superuser
And I have a database "23456789" that is not active
And I am on the home page
When I follow the "Delete" link for "23456789.sqlite"
Then I should see "Deleted the database"
In this story the "When I follow the "Delete" link for "23456789.sqlite" line will not work since the user is no longer logged in!
Have thought about using session or the before/after in cucumber.
Does someone have a clue on how to fix this?
You can achieve this by passing the username in an environment variable:
When /^I am logged in as a superuser$/ do
ENV['RAILS_TEST_CURRENT_USER'] = 'admin'
end
application_controller.rb:
before_filter :stub_current_user
def stub_current_user
if Rails.env == 'cucumber' || Rails.env == 'test'
if username = ENV['RAILS_TEST_CURRENT_USER']
#current_user = User.find_by_username(username)
end
end
end
What's Sinatra's equivalent of Rails' redirect_to method? I need to follow a Post/Redirect/Get flow for a form submission whilst preserving the instance variables that are passed to my view. The instance variables are lost when using the redirect method.
Redirect in Sinatra is the most simple to use.
So the code below can explain:
require 'rubygems'
require 'sinatra'
get '/' do
redirect "http://example.com"
end
You can also redirect to another path in your current application like this, though this sample will delete a method.
delete '/delete_post' do
redirect '/list_posts'
end
A very common place where this redirect instruction is used is under Authentication
def authorize!
redirect '/login' unless authorized?
end
You can see more samples under:
Sinatra Manual
FAQ
Extensions
As for your second question, passing variables into views, it's possible like this:
get '/pizza/:id' do
# makeing lots of pizza
#foo = Foo.find(params[:id])
erb '%h1= #foo.name'
end
The Sinatra Book should clear your question. Especially the "Redirect" part.
Quoted from the book:
The redirect actually sends back a Location header to the browser, and the browser makes a followup request to the location indicated. Since the browser makes that followup request, you can redirect to any page, in your application, or another site entirely.
The flow of requests during a redirect is: Browser –> Server (redirect to ’/’) –> Browser (request ’/’) –> Server (result for ’/’)