Im having a really strange problem with Devise. I have a route set up that accepts both get and post requests. On a get, it shows the form, on the post, it submits it.
When I send a post XHR to the route, when it gets there it tells me that I am not logged in, and sends me a 401 unauthorized. After that I have to log in, and then I can try again.
I have been trying to figure this out for hours, all I have been able to figure out is that my controller method is not getting called. I put in my own custom auth before filter, and it just confirmed that by the time my rails app gets called, the user is no longer logged in.
Also, if I open up the form, but dont submit it, I can continue on as normal. Somewhere in that XHR it is making devise log me out.
If you have any ideas please help, I have no idea what is going on right now...
Thanks
-Scott
EDIT: Adding relevant pieces of code
routes.rb
match 'projects/:p/filebox' => 'projects#show', :via => ["get","post"], :as => 'project_filebox'
projects_controller.rb
before_filter :authenticate_user! # <--- By the time this gets called, the user is logged out
def show
# ^^^^ Doesnt get called. Logger shows that it recognized route though
logger.debug "-----------projects#show"
logger.debug "Current user logged in:"+user_signed_in?.to_s
form that is being submitted
<form class="upload" action="<%= project_filebox_path(#project) %>?n=7&cType=<%= cType %>&fid=<%= fid %>" method="post" enctype="multipart/form-data">
<input type="file" name="file" multiple/>
<button>Upload</button>
<div>Add / Drag Files To Upload</div>
</form>
Javascript that is uploading the XHR
formDataUpload = function (files, xhr, settings) {
var formData = new FormData(),
i;
$.each(getFormData(settings), function (index, field) {
formData.append(field.name, field.value);
});
for (i = 0; i < files.length; i += 1) {
formData.append(settings.fieldName, files[i]);
}
xhr.send(formData);
}
If I missed some relevant piece of code let me know
There's not that much to go on here other than the JS, but there's a really strong change you're having the problem because the CSRF token isn't being set as part of your request. This has changed in various Rails 3.0.x releases so hard to know for sure without code.
One dead simple test would be to turn off CSRF (e.g. remove protect_from_forgery from ApplicationController). If it works, you have the answer and need to make sure the token gets passed around or you otherwise handle forgery protection.
I ran into the same problem when I have two forms in one page, one of them post to an route within then application, the other post to an outside address. John Paul Ashenfelter is right that it has nothing to do with JS.
Like you, I do not want to disable CSRF for the entire site. I ended up disable protect from forgery for the method that is posting to the off site address in the controller:
protect_from_forgery :except => [:some_method]
And in the form that is creating this CSRF problem:
<%= form_for :some_model, authenticity_token: false do%>
Related
# This is the method that defines the application behavior when a request is found to be unverified.
# By default, Rails resets the session when it finds an unverified request.
def handle_unverified_request
reset_session
end
I have seen this explanation at Rails 4 Authenticity Token
now my question is when and how every request sometimes become unverified? how it was hapenning? and when.
thankyou, i have tried to search it but i have seen explanation so deep-technical hence i can understand in an easy way
Rails adds a CSRF authenticity token to form submissions.
If you have a Rails-generated form in your browser and you inspect it, you'll see something like this:
<input type="hidden" name="authenticity_token" value="/LV6706J3W++oCASgg8+wuySgIksE9BNjamMbMW8Zv+G039yyxbpcRpUlUzuVbVvodKtDnUbknwo+jsBzsoO8g==">
Rails checks this hidden tag on form submission to make sure it's the same form that Rails generated in the first place. This helps prevent CSRF attacks
If this field's value doesn't match what Rails expects, it goes to the handle_unverified_request method you mentioned.
And it's not just forms, Rails can add tokens to the session to make sure it can match a request to an active session.
Regardless of the source, if Rails gets a mis-match, it wants to handle that as a security threat.
In essence, Rails is asking you "what should I do when I think the request I received is unverified and potentially an attack?"
In this case, Rails would reset_session which logs out the current_user.
Rails allows you to turn off or limit CSRF protection in cases where you may need to do strange things, but it's not advisable in any instances I'm familiar with.
You can do this by changing the options on protect_from_forgery as mentioned in the SO post you linked.
def handle_unverified_request
reset_connection
# validate only for html submit and not for ajax
if request.post? && !request.xhr? && request.content_type != 'multipart/form-data'
redirect_to controller: 'logout', action: 'index', is_invalid_token: true
end
return
end
and then i have log out controller
if !params[:is_invalid_token].nil?
flash[:notice] = "You dont have access with this."
flash[:notice_header] = 'Forbidden Access'
end
redirect_to :controller => 'login', :action => 'index'
I've just upgraded an app from Rails 3 to Rails 4, and I'm seeing a bunch of InvalidAuthenticityToken exceptions popping up. Digging in it looks like it is fairly common for our users to have multiple long-lived tabs open on our site. So I think what's happening is something like this: user Alice has three tabs open and her session expires. She logs back in on one of the tabs, which updates the authenticity token stored in her session. Then she returns to one of the other open tabs and tries to submit data, but she gets a 500 error from the InvalidAuthenticityToken error we raised.
It would clearly be nice to do some error handling for Alice so she doesn't get a 500 error. I'm wondering about best practices for this kind of situation. What would be a nice way to handle Alice's submission from the expired tab? I don't want to expire the current session, because that would be super annoying from the user's perspective ("I just logged in, you dolt!"). Ideally, I just want the user to reload the page, which would result in the correct authenticity token being present in the form. Or should I be doing something different so that the long-lived tabs that are open notice that the session has expired and force a reload? This would probably be sub-optimal from the user's point of view, because they liked having that page ready and easily accessible to keep referencing, which is why they left it open in the tab in the first place.
In my rails 4.1.1 app I had the same problem. I solved it by adding this code to ApplicationController. I found this solution here.
rescue_from ActionController::InvalidAuthenticityToken, with: :redirect_to_referer_or_path
def redirect_to_referer_or_path
flash[:notice] = "Please try again."
redirect_to request.referer
end
This way any controller that inherits from ApplicationController will handle the error with a redirect to the page the form was submitted from with a flash message to give the user some indication of what went wrong. Note this uses the hash syntax introduced in Ruby 1.9. For older versions of Ruby you will need to use :with => :redirect_to_referer_or_path
The solution to this problem can be divided into 2 phases. Phase 1 addresses the issue of ActionController::InvalidAuthenticityToken error and phase 2 deals with the issue of long tabs waiting idly.
Phase 1(1st variation)
One way to go about is redirect the user back to their location before the error. For ex. if Alice has 3 tabs open, the first one expires and Alice logs in again in it because she was browsing on it. But when she moves to tab 3 which has URL 'http://example.com/ex' and submits a form. Now instead of displaying her an error we can redirect her back to 'http://example.com/ex' with her submitted form values already pre-filled in the form for easy use.
This can be achieved by following this approach:
1) ApplicationController - Add this function:
def handle_unverified_request
flash[:error] = 'Kindly retry.' # show this error in your layout
referrer_url = URI.parse(request.referrer) rescue URI.parse(some_default_url)
# need to have a default in case referrer is not given
# append the query string to the referrer url
referrer_url.query = Rack::Utils.parse_nested_query('').
merge(params[params.keys[2]]). # this may be different for you
to_query
# redirect to the referrer url with the modified query string
redirect_to referrer_url.to_s
end
2) You need to include a default value for all your form fields. It will be the name of that field.
...
<% f.text_field, name: 'email', placeholder: 'Email', value: params[:email] %>
...
This way whenever Alice will submit a form with wrong authenticity_token she will be redirected back to her form with the original values she submitted and she will be shown a flash message that kindly retry your request.
Phase 1(2nd variation)
Another way to go about is just redirect Alice back to the form which she submitted without any pre-filled values.
This approach can be achieved by:
1) ApplicationController - Add this function:
def handle_unverified_request
flash[:error] = 'Kindly retry.'
redirect_to :back
end
Phase 2
To tackle the problem of long awaited tabs you can take the help of SSEs. Rails 4 has ActionController::Live for handling SSEs.
1) Add this to any controller:
include ActionController::Live
...
def sse
response.headers['Content-Type'] = 'text/event-stream'
sse = SSE.new(response.stream, retry: 2000, event: 'refresh') # change the time interval to your suiting
if user_signed_in? # check if user is signed-in or not
sse.write('none')
else
sse.write('refresh')
end
ensure
sse.close
end
2) Give the above function a GET route in your routes file. Lets call this route '/sse'
3) Add this in your layout:
<% if user_signed_in? %> # check if user is signed-in or not
<script>
var evtSource = new EventSource("/sse");
evtSource.addEventListener('refresh', function(e){
if(e.data == 'refresh'){
window.location = window.location.href;
}
});
</script>
<% end %>
Note: using EventSource is not supported by all browsers. Please check out the Browser compatibility section.
Source:
rails 4 redirect back with new params & MDN: Using server-sent events
Answer by Durrell is perfectly alright, I am just providing an alternative way to write the same thing. This needs to go in ApplicationController.
rescue_from ActionController::InvalidAuthenticityToken do |_exception|
flash[:alert] = 'Please try again.'
redirect_back fallback_location: root_path
end
I've just added and configured the devise gem. It's working great except for blocking my form's autosave AJAX calls.
At the top of my controller, I have:
before_filter :authenticate_user!
My AJAX call comes to the same controller:
def autosave
#TODO: update relative entry
#TODO: verify user logged in
#TODO: verify entry belongs to relative user
render content_type: 'text/xml', inline: "<result status='ok' />"
end
Of course I could instead declare my before filter like so:
before_filter :authenticate_user!, except: :autosave
..but this offers nothing to prevent anyone from calling this controller function at any time.
What would be the best way to allow this function to be called? I still want to ensure that only logged in users can make the call and that the given record they're editing belongs to them.
Not entirely sure what you're trying to do, but it sounds like you just need to add a bit of logic to your autosave. With this setup the function will still be called per se, but whether or not it does anything is a another mater entirely unless the conditions are right.
def autosave
#Verify that the user is signed in and he has ownership of entry
if !current_user.nil? && entry.user == current_user
render content_type: 'text/xml', inline: "<result status='ok' />"
else
#do nothing nothing or redirect with error here
end
end
Since you're making an AJAX post you have to provide some additional information to your ajax call as a security countermeasure, namely a CSRF security token. See Devise not setting current_user on Ajax post even though correct x-csrf-token is included in request header for an example AJAX request using a security token. Also, make sure you also include <%= csrf_meta_tag %> in your head tag.
My user experience involves users submitting a form before they've authenticated (using omniauth). I started doing something like this:
def self.require_facebook_authentication!(options={})
before_filter :redirect_to_facebook_if_not_authenticated options
end
def redirect_to_facebook_if_not_authenticated
if !logged_in?
session[:param_cache] = params
session[:original_destination] = request.fullpath
redirect_to '/auth/facebook'
end
end
Then, on hitting the auth callback, redirect to a page that submits a form with the post params inline, for a total of 3 redirects (/stuff/new/ on POST -> auth/facebook -> facebook -> /auth/facebook/callback [ html template with POST form ] -> /stuff/create). I'd rather not create an authentication popup; instead, I'd like to navigate to a separate page, log in, and redirect to the completed action.
I'm fairly new to Rails, so I'm still learning - is this already built in to another framework? Am I missing something really basic? Thanks in advance!
if you are asking as to whether or not there is a "RAILS" way that will automatically post the data after a redirect, the answer is no (see https://stackoverflow.com/questions/985596/redirect-to-using-post-in-rails)
In my opinion the safest, easiest, and most RESTful way to achieve what you want would be to simply have the params you are eventually posting stored in session so that you can redirect back to the original 'new' page and have the form automatically prefilled with the post data. Sure this is one extra step for the user, but since REST doesn't allow for redirects to POSTs it is imo the cleanest way to go about it
There may be a better way, but if you render this after authenticating, then the client will Ajax post the form contents then redirect.
<script>
new Ajax.Request(<%= session[:original_destination] %>, {
method: 'post',
params: '<%= session[:param_cache].to_query %>',
onSuccess: function(){
window.location = '<%= session[:original_destination] %>';
}
});
</script>
I am using Authlogic to do some simple signup and login stuff. In my WelcomeController I want to have the signup and login forms on the same page 'index' with form actions set to their individual controllers, UsersController and UserSessionsController, respectively. These controllers redirect the user to the protected profile page within the site on successful signup/login. On error I need to redirect back to the WelcomeController#index and display their errors. Upon doing a redirect this information is lost and I cannot use a render because it is a different controller. What is the correct way to handle this behavior?
I could perhaps store the error messages in the Flash Hash. This seems like the easiest solution.
Lately I have stumbled across this problem in another application I was writing where I needed to render summary pages from researcher submitted RFP forms from a PeerReviewerController. Seemed like in that case the use of now deprecated components would have been the right way to handle this. ie: render_component :controller => 'RFPForms', :action => 'summary', :id => 213
Components seem like the DRY way to do something like this. Now that we don't have them what is the correct solution?
One simple and easy way to do this is to pass a parameter on the redirect:
redirect_to welcome_url(:login_error=>true)
In your view or controller you can then test for that param:
<% if params[:error] -%>
<div class="error">My Error Message</div>
<% end -%>
You could do a render:
render :template => "welcome/index"
But you'd have to make sure that any variables that page expects are loaded, or it won't render.
Drew's answer does not cater for more complex error data (e.g. an array of validation errors), and Marten's answer would risk violating the DRY rule by needing to duplicate code from WelcomeController#index.
A better-looking answer (which is an elaboration on the original poster's idea of storing error data in the flash) is available in Rails validation over redirect although unfortunately I am still personally struggling to get it working ...