I am using rails 3.2 and devise 1.5.3.
I added an admin attribute in my model as described in option 2 on the devise wiki How To: Add an Admin Role
I added this in a post controller for force logins:
before_filter :authenticate_user!
I wrote some logic to hide the edit/new links in my views based on whether you're an admin or not.
I feel like there's more I should be doing.. Should I add anything else to new/edit/delete actions to make them more secure? If so, where?
your answer may be working but it is pretty difficult to ensure security in the whole app if you are using some logic to hide the edit/new links in my views and I'm pretty sure no amount of security testing would give you the feeling that maybe you are forgetting about something
for example I someone could log in,,,, (not having admin profile) and go to (in the URL),:
/users/edit/3 and start damaging your valuable information....
situation is: Devise only provides authentication,,, but authorization has to be enforced in some other way or else I could be able to do the above things...
for that I would highly recommend CanCan (from rbates ofcourse) which is the one I have tested personally and is PRETTY easy to configure just by reading the docs and examples in github..... hope it helps!
Your authentication and authorization mechanism is in charge of taking care of security for you, and you should make sure it's regularly updated with security updates.
That sinking feeling that you have about missing something can only reliably be covered by tests. So, write some tests that verify that the way you've setup your Devise installation is, in fact, correct, and they non-admin users do not have access to anything they shouldn't have access to. Then be very careful to make sure you update your security restrictions as you add new things.
You don't need to write tests to make sure Devise works - but you do need to write tests to make sure that your use of it is what you think it is (i.e. if non-admins shouldn't be able to get to the admin page, write a test that logs in as a non-admin, try to access that page, and verify in the test that the user is redirected and, if you have an 'access denied' message, that's it's firing). That way, if you inadvertently break security access later, you at least stand a chance that it'll be caught by a test in your test suite.
Run your test suite before every deploy, making sure that all tests (especially security tests) are running and passing. Then be vigilant thereafter, and that's about all you can do.
Related
Is there any simple way of adding a required param for registration on Devise?
I added Devise since I thought it should "handle users for me" but as it seems to be going everything I want besides the basics seems to be a hassle...
I already added the parameters, the thing is I can't find how to make it required... Or how to easily override the signup method and make the check myself.
"Out of the box" the Devise gem is very powerful, but when you start to step out of the box there is a significant amount of modification that has to be done to the underlying code.
I was a big user of devise when I first started using Rails. However in the last year I have found it easier to create my own authentication. Do a google search on 'rails authentication from scratch'. There are lots of good blog posts on the topic.
Building your own authentication is not terribly difficult, and gives you the flexibility to add whatever fields and customization you want. Additionally its lightweight (you only build what you need), and you are not exposed to the whims of gem updates and changes. Finally, you get the satisfaction of knowing you built it yourself.
Good luck!
I found the solution, you should add to your model
validates_presence_of :username
(and in my case)
validates_uniqueness_of :username
that should make devise automatically validate and through errors if something goes wrong.
What is the best practice to test non-functional requirements in a rails 3 application like authentication or authorization which are implemented as before filter in the controllers. Should the functional tests are used where may be the existence of the certain before filters are checked or is it an issue for the integration tests where you try login with wrong credentials.
I have read a lot of other posts but didn’t find a proper solution.
Thank you for all answers.
Inside of functional tests for a given controller I will usually include the tests such as "make sure the user is redirected to the login page if not logged in", or "make sure the index page is rendered if the user IS logged in".
Ultimately I think it is a style decision, but I consider what is protected via login and what is not, to be part of the functional spec of the application. Hope this helps!
I'm trying to create a login system in Rails 3 where I can access the logged in user not only from the views but also from the controller/model level. The reason is that I want to adapt functionality according to a privilege system where logged in users may execute different functions than those that are not logged in.
Up to this point, I tried to implement the login system from railstutorial.com, chapter 9.
When I use the login system only from the view, it works. However, if I try to use the system via a controller, I get the error undefined method 'cookie_jar' for nil:NilClass.
Thank you for any help or best practices you can provide for creating an authentication system where the logged in user can be identified from a controller.
The best advice here is probably "don't". If you want an authentication system, use something like Devise - which has had a lot of time and effort spent making sure that evildoers can't get in
If you want different users to execute different functions, this is access control, and for that you probably want something like cancan or ACL
And you want access to the logged in user from the model level? Again, the best practice is "don't". The model should have no interest in the currently logged in user - that is a matter for the controller.
(That said, rules are sometimes made to be broken - if you are doing an audit trail and need to store information about the user who made a change, for example, passing the currently logged in user to the model may be the best answer ....)
And finally, if you really, really want to do it all from scratch, take a look at this railscast
An extremely simple way is to do it as mentioned in railscast episode : http://railscasts.com/episodes/20-restricting-access
As mentioned in the screen cast, you can use the plugin acts as authenticated (http://www.railsrocket.com/acts_as_authenticated-plugin) for all your user model needs.
If everything done according to the tutorial you should be able to get current_user from both controllers and views. There's also another tutorial on authentication on asciicasts.com by Ryan Bates. You may want to explore it if you are just starting Rails, but for real-life applications it's highly recommended to use Devise or AuthLogic, which are thoroughly tested and constantly evolving.
First, my obligatory "I'm new to rails" statement: I'm new to rails.
Sorry for the following long-winded expository stuff, but I want to make sure I'm asking my question clearly. I'm building a sample manager for a small analytical lab. So far I have built the core user stuff using devise to manage sessions (Basically so I can use all of Devise's nice helper methods throughout my app). The users don't need to be securely separated, so there is no sign in form, it just automatically signs them in for whatever action the user wishes to do.
I would like to put a front door on the website for macro-security that signs in to either the user version of the site (described above) or the admin version. I understand how to implement this using Devise, however, I am unsure as to whether Rails allows this sort of double-session where there's a macro-security session on constantly while a bunch of internal sessions are created and destroyed. Again, sorry for the long-windedness and thanks for your time and help!
Decided to just give it a shot and it turns out it worked. I have to test to see if there are any kinks in the functionality, but as it stands it works well as a front-door while allowing the internal transient sessions.
I've managed to setup authlogic, and quite nice it appears too. Is it secure enough out of the box?
I haven't really configured it too much. I'm going to be using it on a school website where the headmaster basically logs in with username and password to edit notices on the website. So it needs to be secure, but it ain't a bank or an e-commerce site or anything.
All I've done is restrict access to all the edit pages so you need username password and was going to leave my security at that. What do you think?
Restrict access to new, create, edit, update and delete (so only show actions are 'in the clear').
Other than that, I've never come across mention of any Authlogic security issues with a default configured Authlogic setup. Most of the configuration options are provided for dealing with specific requirements imposed by certain environments rather than something that is required for clean environments.
Be sure to add functional tests to ensure that anyone who is not logged on cannot do new, create,edit,update and delete actions. The beauty with tests in this situation is that sometimes they weed out things you may have missed in the initial coding.