Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow impersonating when already impersonated #139

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Allow impersonating when already impersonated #139

wants to merge 1 commit into from

Conversation

claudiodekker
Copy link

@claudiodekker claudiodekker commented Apr 29, 2021

This PR hopes to solve a situation where you can't re-impersonate when already impersonated.
The problem I'm trying to solve here has to do with the following situation:

  1. You impersonate as an user, do a support-like thing or whatever, and afterwards forget to reverse-impersonate
  2. You impersonate another user, get a 403 (because you can't impersonate twice)
  3. You click back
  4. You click reverse impersonate / leave impersonation or whatever.
  5. You re-impersonate the user again by re-clicking the impersonate link (step 2)

Please note I didn't test this, but it seems rather straight-forward to me.

Thanks!

@jose123v
Copy link

It's a shame it doesn't have any reviews.

@drbyte
Copy link
Contributor

drbyte commented Feb 28, 2024

I'm not convinced this is the best way to solve this "problem".

What I've done for this is simply to block the Impersonate option in the UI if the user is already impersonating.
Granted, in most of my apps it's only Admins who can impersonate others, so most of the time they'll never be impersonating someone who would even see a button to impersonate yet another user.

Another thing I did in one app was apply a header bg color change when impersonating, so that it's always obvious that you're already in impersonation mode (the users of that app were often accidentally editing things wrongly while in impersonation, and they were satisfied that this header bg color/overlay was enough of a clue to be cautious.)

Anyway, checking "can impersonate", "can be impersonated" and "already impersonating" for UI components will often be enough for this, and can be done in existing apps right away without package changes.

Copy link
Contributor

@drbyte drbyte left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this PR gets approved, I think it would be wise to first check canImpersonate() before checking isImpersonating(). Swap the checks. eg: It might be unexpectedly surprising to try to impersonate someone else who can't be impersonated and then forced out of the impersonation you were already in.

eg:

+        // abort if destination user cannot be impersonated
+        if (!$request->user()->canImpersonate()) {
+            abort(403);
+        }
+
+        // if already impersonating someone else, leave impersonation
        if ($this->manager->isImpersonating()) {
-            abort(403);
+            $this->manager->leave();
        }

-        if (!$request->user()->canImpersonate()) {
-            abort(403);
-        }

I suppose a config switch could be added and checked inside if($this->manager->isImpersonating()) to control whether $this->manager->leave() is called vs abort(403).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants