A user, bloomingcrystals, encountered an issue with the impersonate feature in Discourse after recursively impersonating accounts. After setting up a test environment with SSO, they used their admin account B to impersonate another admin (A), then impersonated a bot account (C) while still impersonating A. This led to a situation where account B could no longer impersonate A or C, with the impersonate button missing. The issue was resolved by adding account B to the DEVELOPER_EMAILS list in the app.yml configuration, which restored impersonation capabilities. IAmGav provided the solution, explaining that only developers can impersonate admins, and JammyDodger suggested logging out of all accounts to reset the impersonation state. The user confirmed the fix worked but remained unclear why impersonation initially worked.
I set up a discourse server for a client and let them create test accounts, which I knew will ultimately become obsolete once the SSO was in place. I set everything up, customised my theme and wrote category descriptions for everything using my admin account A.
Once I had DiscourseConnect setup (as the only sign-up option) I signed in with my admin account from the other system and granted that account B admin rights. From here on I would do anything under account B, as I couldn’t log in as A anymore.
Then I happend upon the “impersonate” button and got curious. Seemed like I didn’t have to delete account A, if I could just impersonate them to edit category descriptions, FAQs etc. So I used B to impersonate A and did a bunch of edits to test and everything was great.
Until I got curious if I could impersonate the forum’s bot account as well. So, while still impersonating A (who happened to be an admin) I decided to impersonate C. It worked, great stuff, so diligently I logged out and went about my day.
Now, when logged in as B I can no longer impersonate A or C (other users are fine). The spot where the button should appear just reads “Admins and moderators can’t be deleted”.
The logs say that “B impersonated A” and “A impersonated C”.
I wasn’t sure whether this warrants a bug report - as I currently have no way of reproducing my steps - or if there was an easy way to fix this?
I didn’t know this route existed! That definitely solves the problem of circumventing DiscourseConnect, though I haven’t been able to untie the knot so to speak. Impersonate buttons show up for user A though, so I’m assuming they’re currently not impersonating anyone?
I just wrongly assumed that if you’re deliberately hiding the information from admins, then it wouldn’t be public. 2.8.0.beta4 it is.
Regarding your second suggestion, I don’t want to do that as user A has no equivalent on my other system, however any user can potentially have an account on the forum.
That’s about the bottom of my tiny barrel of knowledge. I wasn’t sure if admins could impersonate other admins (I thought it was only developers). Did you remove Admin B from this list?
Hopefully someone with deeper knowledge pockets can chip in with something more salient.
I would suggest you add your Account B to the Dev section in the app. yml like @JammyDodger mentioned.
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'gavin@truecode.co.za'
)
