Great video, can you explain more about the page.resources? where that is coming from and how it contains the user info for that method. Thanks
It's the resource for the current page that you're viewing inside Administrate. Just their naming convention since the admin is generic for any models you may have.
Awesome tutorial! Personally I found this plugin to be a much simpler alternative when adding this feature a few months ago, but both are very good nonetheless: https://github.com/ankane/p...
There's a bunch of great options like this. Cool thing about Pretender is that it can work with anything, but the nice part of devise_masquerade is it handles all the controllers and routes for you.
Authenticating as another user via admin console is a really nice idea. It may save a lot of time for QA. You inspired me to try something like this in one of my projects. But there is a bit different situation:
1. I have separate model for admin console users.
2. Admin console is running on a separate domain (this is the same Rails app with one common DB though).
Aparently in this case I'll have to implement custom solution instead of using devise_masquerade gem. Here's my idea:
- Authenticated admin clicks a link on admin console to sign is to primary application as some specific User.
- Application creates authentication token and saves it to DB. Something like this tuple: `AuthRequest.create(secret_token, target_user_id, token_expiration_time)` (assuming we have AuthRequest model to keep authentication requests).
- After token is persisted, admin console redirects the admin to primary application, using full URL with different domain name. `secret_token` should be one of the parameters for this request.
- Primary application validates secret token and authenticates current user with associated User records. Like so (the code is simplified):
# Assuming this is an action that suppose to handle admin console redirects
auth_request = AuthRequest.find(param[:id])
sign_in(auth_request.target_user) # Calling Devise helper
auth_request.destroy! # Eliminating authentication request record
But may be there are more straightforward ways to do this. I'll be grateful if you share your opinion.
That seems like a pretty decent solution cross-domain. Since you're sharing the database between the two, you can verify the token is only allowed for the user it was generated for and your expiration can be like 30 seconds so that the chance of that token leaking is very small.
You can also scope that AuthRequestsController to only allow admin users to access it as well so you get the same security around these tokens that devise masquerade does when it's only accessible from the admin.
Sounds like that'll work pretty nicely.
Hi Chris, firstly, thanks a lot for your videos! They're so valuable!
My first question is related to using masquerade together with the friendly_id gem. I noticed masquerade_path(@user) is redirecting to /users/masquerade/chris, for instance. If I hardcode the user id - like in /users/masquerade/8 - it works. Any insight on how can I make it work properly?
Also, and even more important: if any user tries to open this URI, even if he's not an admin, he's able to access other users' accounts \o/ won't that happen in your application as well?
Since this is an administrative thing, you could explicitly pass in the user id like this:
masquerade_path(@user.id) which should always put the numerical ID in, or you could take a look at overriding the masquerade query to use the friendly.find that is required for friendly_id lookups. I'd probably just pass in the ID explicitly since it's only accessible to admins.
And you can make sure this is accessible only for admins by doing this if you're using CanCan or putting your own before_action in the overridden controller to authorize for only admins: https://github.com/oivoodoo...
I don't think I mentioned authorizing that url in the episode like I should have. That's an important piece!
current_user is still returning the user I am originally logged in with.
Any help appreciated. Thanks.
Join 31,353+ developers who get early access to new screencasts, articles, guides, updates, and more.