i'm trying to verify in my controller whether user has sufficient rights to upload files or not. swfupload does a POST request with (according to documentation) cookie values passed directly in POST request. this makes before_filter :authenticate_user! unusable, user is not authorized correctly.
as far as I know from devise docs, there is a possibility of creating custom session controllers. is it a good starting point to solve this problem? any idea how to extract session id from POST and proceed with authorization?
I had a similiar issue with swfupload. I used midleware and some custom helper links to make it work. More info here: http://thewebfellas.com/blog/2008/12/22/flash-uploaders-rails-cookie-based-sessions-and-csrf-rack-middleware-to-the-rescue
Related
I would like to understand briefly how the authorize filter and FormAuthentication.SetAuthCookie work under the hood. It's the only thing I find ambiguous after reading some books on the language.
I don't understand how the authorize filter knows where to look. And what about FormsAuthenticationTicket VS FormAuthentication ? And is cookie the most secure way, I mean I'm sure it's possible to export the cookie from a browser and use it somewhere else..?
You might find this question helpful.
If you're interested in how the Authorize filter works in more detail you can review the source code: AuthorizeAttribute
Briefly the Authorize filter will check whether the user has been authenticated by checking the HttpContext.User.Identity.IsAuthenticated property. The User property will have been set by the FormsAuthenticationModule in the case of Forms Authentication.
The FormsAuthentication.SetAuthCookie method creates a ticket for the authenticated user (assuming the user has provided the correct credentials) and adds it to the cookies collection of the response. Alternatively the module can be configured to use cookieless authentication if you want but the encrypted ticket is still sent with each HTTP request. Either way the client (browser) needs a way of telling the server that the requested is authenticated.
Regarding your concerns over security there are some ideas in this question.
In my application I have at this point a authentication function through oauth, but before of that I would like to have a login page, so I want to use Devise to create that. The problem that I am facing is that bought Device and my authentication method require a before_filter, and both methods redirect to a page, and because of that I get an error saying that I have to redirects. How can I fix this problem?
Thank you
I don't know explicitly what you are doing and what are your actual requirements but as far as I know you don not need before filter. you need to provide both options for login, authentication with devise and Omniauth.
I am referring you to some links consult it.
Mandatory:
http://www.samionrails.blogspot.com/2013/08/google-omni-auth-with-devise-tutorial.html
Optional:
https://github.com/intridea/omniauth/wiki/Managing-Multiple-Providers
http://www.samionrails.blogspot.com/2013/08/authenticate-user-using-omniauth.html
What is the best way to make authentication?
on frontend I use Angular.js
on backend: Ruby on Rails
Rails app using as API for my frontend.
UPDATE:
This is will be single page application.
Frontend wiil be developed in Angular.js, backend in Ruby on Rails.
In ideal I want to build backend as collection of resources returned in json.
I search best method of security implementation.
When user open the app I need to check if user authenticated.
If not - go to login page,
If authenticated - open that he wants and return needed resource from backend.
I think that I need to store auth token on the client side.
What is the best method to generate it, or maybe Rails already generate it for me?
I don't know Angular.JS at all but I will try to provide you general information on rails that you can use with any Javascript Framework.
For authentication, you just needs:
A model for users
a controller which handle login, this method check user login/password, create a session object with all information needed (session is stored on server side and a cookie is used on client-side to associate each request to a session)
A controller for handling logout which basically only destroy the user's session
You have a good implementation in the rails tutorial here, or you can find several plugins (authlogic seems to be the recommendation of stackoverflow usershere).
Then, there is few differences between handling authentication with static html pages or with AJAX:
A HTML request will send login and password to the controller, which will automatically redirect it to another internal page once the session create
In AJAX, the javascript on client side should send an ajax request, look for the answer by the server (success / failure) and launch adapted actions (message if failure, redirection if success)
In both cases, the important thing is to check that the user is authenticated at at each controller otherwise anybody would be allowed to launch action or access internal information.
I'm trying to do something similar and I found this example app which has been very useful to get me going in the right direction: https://github.com/karlfreeman/angular-devise
Also checkout further discussion about it here: https://github.com/karlfreeman/angular-devise/issues/1
And here's another repo which takes a slightly different approach: https://github.com/colindensem/demo-rails-angularjs
I ended up borrowing ideas from all of the above. Here's a working demo if anyone's interested: https://github.com/jesalg/RADD
I'm fairly new to Rails and I'm trying to implement a really basic user authentication system. My main problem right now is that I do not have a clue what's a good design for this.
What I have now
My Rails app is not a website; it's a webservice that communicates with an iPhone app. All communication is in JSON.
When a user signs up, the app sends a POST request to /users.json with name and password as JSON in the HTTP body. Rails then saves the user id in a cookie:
cookies.signed[:user_id] = #user.id
When a user logs out, the app sends a POST request to /logout.json. Rails gets the user id from the cookie, updates the database and deletes the cookie.
Later, when the user wants to log in again, the app sends a POST request to /login.json with name and password as JSON in the HTTP body. Rails sets the cookie again.
My question(s)
Is this design RESTful? Because login and logout aren't resources.
Is it secure to use cookies like this? I'm planning to use SSL.
Is there a better way to do this?
Tt's a very basic approach
A more RESTful way:
Create a controller called sessions with a create and destroy action. Throw the login/logout out of your head and start thinking in sessions. A login is just a username/password combination. When you login you create/start a session, when you log out you destroy the session. The login is not affected.
Instead of using cookies.signed[:user_id] you should use session[:user_id]
SSL is a big plus, because the password can't be sniffed through the network.
And there are lots of out-of-the-box authentication systems.
My favourite is Devise:
https://github.com/plataformatec/devise
http://asciicasts.com/episodes/209-introducing-devise
http://railscasts.com/episodes/209-introducing-devise
there is a nice screencast ryan bates did on authentication from scratch
http://railscasts.com/episodes/250-authentication-from-scratch
No, for the reason you stated.
No, you need to pass a second parameter to encrypt the user's id.
Well, you could use a gem, there's a few about.
If you do want to code it yourself, then I'd recommend looking at a tutorial. The one at railstutorial.org is pretty good.
The basic idea is to create a user model with an encrypted password, which uses a salt formed from the current time and password. You then create a sessions controller and make it RESTful, but using cookies instead of another resource. Make sure to encrypt the cookie with the salt as well:
cookies.permanent.signed[:remember_token] = [user.id, user.salt]
I have an app I'm writing in rails 3 w/ cancan and devise. I'm curious if authorizing post actions on your controllers is necessary or helpful from a security standpoint? Assuming all my controller actions require authentication w/ devise (ie user must be logged in).
I can see why I need authorization through cancan on my controller actions that use GET's since a user can simply input the url they wish to visit freely and this must be locked down. However, with posts the user must post the data from a form, which is protected against an xss attack with a token.
In this case would it be safe to assume that if i limit the visibility of, say, a button in my view with cancan that the user wouldn't be able to submit a form maliciously?
Thanks alot
EDIT:
Thanks for the quick answer guys. As it has been pointed out below a malicious user can forge a form post using tools such as firebug and thus authorization is necessary.
What would be the best way to simulate this type of interaction (a user posting to an url with a form they've hacked) using capybara / cucumber?
Thanks again.
A user can submit a POST request regardless of whether they are on your website or not. You're correct in thinking that the security token will help prevent XSS, but I would add authentication in for other methods of attacks.
A good (free) ebook to read if you're concerned about security is the Ruby on Rails Security Guide. It outlines all common forms of malicious attacks and even explores some of the lesser used (but just as effective) methods. It also gives great solutions on how to make your application more secure.
You should validate a users authorization in the controller.
With simple tools like FireBug, you can edit the content of a form manually and even add more text fields or similar. The XSS protection won't help you with that.
The user would still be able to generate the button (any method from using Firebug to changing browser code would do) on client side and send the form. If I remember correctly tokens are sent in HTML header co it wouldn't be a problem to forge the form.