Impersonation and programmatical login

[igor-alexandrov]

Hello,

I want to provide an ability for admins to impersonate an existing account.
I created a separate configuration for this.

# frozen_string_literal: true

class RodauthImpersonate < RodauthBase
  configure do
    enable :login, :logout, :internal_request

    session_key_prefix "impersonate_"

    # ==> Redirects
    # Redirect to home page after logout.
    logout_redirect '/'

    # Redirect user to their company page after login. Works only if `login_return_to_requested_location_path` is nil.
    login_redirect { rails_routes.company_path(rails_account.member.company) }
  end
end

And call it like this:

def impersonate
    rodauth = Rodauth::Rails.rodauth(:impersonate, account: Member.find(params[:id]).account)
    rodauth.login('impersonate')

    redirect_to company_url(resource_member.company)
end

I have no errors, but it simply does not work.

Do you have any ideas on implementing this and what I am doing wrong?

Thank you.

[janko]

Yeah, this example won't work, because Rodauth::Rails.rodauth goes through the internal_request feature, which doesn't have any connection to the current request, so it cannot update the session.

I don't know what's the best way to implement this. My gut tells me that a separate configuration isn't ideal, because then in places where you're calling e.g. rodauth.require_authentication you also need to call rodauth(:impersonate).require_authentication. I think it's better to use the main configuration for impersonation, assuming admins have their own separate configuration & sessions in your app. Something like:

def impersonate
  rodauth(:admin).require_account # only admins can impersonate accounts

  account = Member.find(params[:id]).account

  rodauth.account_from_login(account.email)
  rodauth.login("impersonate")
  # if main configuration is using multifactor authentication
  rodauth.two_factor_update_session("impersonate-two") if rodauth.uses_two_factor_authentication?

  redirect_to company_url(resource_member.company)
end

And then in your layout you could add a banner or indication notifying the admin that they're impersonating another user:

<% if rodauth(:admin).authenticated? && rodauth.authenticated? %>
  <div>You're impersonating user <%= rodauth.rails_account.email %></div>
<% end %>

When logging out from impersonated account, you just need to be careful to avoid clearing the admin session as well, because by default the whole session is cleared. I don't remember now what's the recommended way to do that.

[igor-alexandrov]

Thank you for the clarification. I will implement it and come back to you.

[igor-alexandrov]

Sorry for disturbing you again.

I decided to combine my original idea with yours. So I still have a separate configuration to impersonate users. It still seems to me, that it would be easier, but again I faced problems.

This works:

account = Member.find(params[:id]).account

rodauth.account_from_login(account.email)
rodauth.login("impersonate")
# the line below will never be executed, because `login` makes a redirect. Probably better to use `login_session`
rodauth.two_factor_update_session("impersonate-2fa") if rodauth(:impersonate).uses_two_factor_authentication?

However this does not work and rodauth(:impersonate).rails_account is nil.

account = Member.find(params[:id]).account

rodauth(:impersonate).account_from_login(account.email)
rodauth(:impersonate).login_session("impersonate")
rodauth(:impersonate).two_factor_update_session("impersonate-2fa") if rodauth(:impersonate).uses_two_factor_authentication?

Don't really have any ideas where is the problem.

[igor-alexandrov]

Okay, I cloned the demo app, and I found two things:

1. You cannot have two active sessions at the same time. To reproduce this, sign in to admin, then follow /admin/impersonate path, and you will get logged in as an impersonated user, but your admin session will no longer exist.

2. It seems I also reproduced my original bug: sign in as a regular user, then go to /admin and try to sign in as admin. You will see that based on SQL queries, you have been logged in, but you are getting redirected to /admin/login. This cannot be reproduced if you first sign in to /admin and, after this, will try to sign in as a regular user.

[igor-alexandrov]

My original idea was to have two sessions at the same time, with different identifiers. I 100% sure, that Authlogic allowed to do this.

[igor-alexandrov]

Okay, this happens because on each login, clear_session method is called, and it does not care about prefixes or something. It just clears the whole session values.

Seems like it should clear only the keys related to the configuration that initiated the login.

[igor-alexandrov]

Ok, I found a solution. As I written above clear_session deleted all session keys, no matter what configuration created them.
My main configuration had remeber feature enabled. So here is what happened:

1. You click on "impersonate" button
2. Controller action logged in impersonated user
3. clear_session was called, and removed all session keys
4. remember feature from the main configuration checked that session is not valid (it didn't exist) and restored it and called clear_session again, which cleared impersonated user session.

Don't know is it a bug or not, but for now I fixed this by redefining clear_session.

# frozen_string_literal: true

class RodauthImpersonate < Rodauth::Rails::Auth
  configure do
    enable :login, :logout

    prefix '/impersonate'

    session_key_prefix 'impersonate_'

    logout_redirect '/'
    # logout_notice_flash nil

    login_redirect nil
    login_route nil
    # login_notice_flash nil
  end

  def clear_session
    session.keys.each do |key|
      session.delete(key) if key.start_with?(session_key_prefix)
    end
  end
end

[janko]

Ah, that makes sense. It seems that the main problem is Rodauth resetting the session regardless of whether other configurations have their session data as well. While gems like Devise/Warden store session data in a sub-hash within a single top-level session key, Rodauth stores all session data on the top level, and doesn't currently store a list of its session keys.

I considered adding the ability to Rodauth for storing session keys in a sub-hash, and in general allowing multiple configurations to be logged in at the same time, but I never started. I would suggest proposing this to Jeremy and see what he thinks, as I remember others getting bit by this as well in the past.

[igor-alexandrov]

Thanks @janko I will ask Jeremy.