I'm using devise on rails3 and I'd like to implement "su" with it.
To debug my application, it sometimes helps a lot to see exactly what the user who is having the problem is seeing. Therefore I would like to have the possibility (as an admin) to switch to that user without needing to know his password. Just like su on linux systems.
I've seen it done for authlogic (http://blog.steveklabnik.com/2010/03/05/writing-a-su-feature-with-authlogic.html).
The final outcome should be, that when I call /admin/su/5 as a User with the role "admin" I should be logged in as the user with id 5.
Any help or pointers into the right direction are creatly appreciated.
From Mike Barinek
Fast user switching with Devise
This sounds like what you're requesting, and even includes cucumber specs.
Related
I use the Clockify API to sync objects to and from our other databases.
I try to update the user image from our LDAP user repo; works fine on my own account, but when I try to update the image for someone else I get a 403.
That leads me to the conclusion that everything under /users is only available for the current user (even if the current user is admin of the workspace). If so, can that be clarified in the documentation?
https://clockify.github.io/clockify_api_docs/#tag-User
Is there a way to update user settings/profile for someone else?
That's right. By design, you can't edit other people's User Settings.
This is because the person in your workspace might have other workspaces (be it their own or someone else's). You're only someone's admin in your particular workspace, and they're free to have other workspaces beside yours.
Looks like you are right, I can't GET users/{userId} except for my own user ID. Attempting to get it for other user IDs, even those users on my team and I'm the owner/admin, gives the 403 Forbidden.
I would recommend reaching out to support#clockify.me, they may be able to fix it - or at least they can be made aware of the issue. I've had success in contacting them and they respond relatively quickly.
I have an corporate intranet project that needs logins, but doesn't need high security. Impersonating a different user is not useful or very desirable. In similar intranet systems, everyone has the same password as setup by the admin.
I'm hoping to get some suggestions on what password alternatives I could consider. My first thought is to show each user 8 images and have them click on one to be their password. Would this be too annoying or problematic in someway? What other ideas would you suggest?
Why not just use a text based password? It sounds like you are over-complicating things by including images, especially if, as you stated, don't need "high security". I wouldn't consider a text based password "high security" but it does meet your requirements of a login on the intranet. A lot of products have built in functions for passwords so it would be dead simple to implement into your project if you have this available. I'm suggesting you keep it simple and don't assume that impersonating a user isn't something that won't happen without at least a password. You'd want to know who made changes or have some logs that identified who was the user at the time of a certain event.
Remember, security should be baked in, not sprayed on!
I'm creating a Rails app using Devise for user management (Rails 3.0.10, Devise 1.4.2). I've got the basics going - signup, login / logout - but I can't seem to find any facility (or even documentation surrounding) user management.
In other Rails apps I've created, I've had a UsersController with an index method that allows an administrator to list all the users of a system, & to subsequently modify them through edit and update actions on the same controller.
I can't see an obvious way of doing this with Devise. I've used the Rake tasks that come with Devise to generate editable views, which is great, but I can't figure out how to do the equivalent with the Controller.
I fear I'm missing something fundamental here. Could someone please point me in the right direction?
Devise doesn't come with any sort of Admin interface. If you are the only administrator and don't mind a little crudeness - there is always the console and/or scaffolding.
There are also a lot of good gems that make setting up admin interfaces a cinch: Active Admin, Rails Admin and I'm sure there are a bunch more out there.
I've got a rails 3 app in beta right now that uses Devise for authentication for users, and need some advice. I want to add an admin-user that has some additional abilities, but I will be the only admin user (or admin users can be created via terminal - ie people cannot sign up to be admin users). All regular users have the same abilities. I was just about to use cancan to separate abilities based on user roles. Then it occurred to me that using cancan may just be overkill. does it make sense to just create a different class of user instead? Am I giving anything up by doing this?
I can foresee in the future that if this app is successful, there may be different roles for users (a free versus paid account, etc). Even in that case, does it make sense to NOT have an admin user via devise? Thoughts?
Thanks!!
If you only have two types (users and admins) it seems perfectly fine to have two classes. It might even be easier to implement than a full-fledged role system. But if it is foreseeable that you will get more roles in the future it would be better to lay a solid foundation and use a role system from the start.
If you are the only admin, I would create a field in your user model called Admin and then when you are going to add a function that is only for you, use the admin? check in your code.
For most of my projects, I have been using Devise and then use Option 2 from their Admin Role Wiki which is super easy to implement.
I know the title is a little off, but it's hard to explain the problem in a short sentence.
I am the administrator of a legacy webapp that lets users create surveys and distribute them to a group of people. We have two kinds of "users".
Authorized licenseholders which does all setup themselves.
Clients who just want to have a survey run, but still need a user (because the webapp has "User" as the top entity in a surveyenvironment.)
Sometimes users in #1 want us to do the setup for them (which we offer to do). This means that we have to login as them.
This is also how we do support: we login as them and then follow them along, guiding them.
Which brings me to my dilemma. Currently our security is below par. But this makes it simple for us to do support. We do want to increase our security, and one thing I have been considering is just doing the normal hashing to DB, however, we need to be able to login as a customer, and if they change their password without telling us, and the password is hashed in the db, we have no way of knowing it.
So I was thinking of some kind of twoway encryption for the passwords. Either that or some kind of master password.
Any suggestions?
(The platform is classic ASP... I said it was legacy...)
Both options you present sound unattractive to me.
A master password is probably even more dangerous than what you are doing right now
Encrypting (instead of hashing) passwords in the database is not good enough either IMO, as it takes only a break-in on your end to get hold of all passwords. They really should be hashed.
I assume the product, being an old legacy app, is impossible (or not economically feasible) to change in a way that administrator accounts can impersonate user accounts, which in my opinion is still the best approach to this in a real-world scenario (not everyone shares that opinion, discussion on the issue here).
How about introducing a second password column (password2) containing a hashed password that you enter? The login process of the app may be easy to tweak into looking in a second column as well. It might be easy to implement, and I can not see any additional security problems coming from it (correct me if I'm wrong of course.)
What I would do is to let the support staff login with their username/password but to chose a user to "impersonate". So in your session you will have:
logged_user - the actual user who typed in his/her username and password
impersonated user - the user (1) is acting on behalf of
Everything you do is done with the impersonated_user's permissions and preferences.
If you are not impersonating anyone impersonated_user=logged_user.
This way you have to always log any operation with both "actual" username and "impersonated" username; for example:
2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie'
sounds like you want to decouple your authentication from your identity a bit. Maybe something like an administrator override page, so that after you log in as the administrator, you have a choice of which user identity you wish to assume. After selecting an identity, you continue to use the app without further authentication.
I like the solution offered by Manrico Corazzi. It reminded me that when you need support from Microsoft, there is way to hand over the control of your machine to a technician. That could be another way to achieve the impersonating mechanism. In order for an administrator account to log in, an authorized license-holders would have to explicitly allow him to join his session and act with all his privileges.