Authenticated Users See Unmasquerade Link in Toolbar

I must be very tired, this does not apply to the issue...

Looks like changing this value in masquerade.routing.yml
_user_is_masquerading: 'TRUE'
to
_user_is_masquerading: 'FALSE'
removes the link from users other than admin

unsure what happened, but the link is now gone for me in my normal user accounts. After removing and reinstalling Masquerade module, the link is still gone from normal accounts. So I'm guessing this is something on my side.

However, below still returns false, so it does not show a link to unmasquerade for those users currently masquerading
getContext() in MasqueradeCacheContext always returns FALSE for me, even when the $_SESSION['masquerading'} value is set

Again, looks like I'm tired, this does not apply to the issue
Looks like the module is using $_SESSION most places, so switching from
$this->requestStack
->getCurrentRequest()
->getSession()
->has('masquerading');
TO
return (isset($_SESSION['masquerading']));
gives the masqueraded user the "unmasquerade" link back

I'm also facing this issue, however only with the user account menu. The Admin Toolbar seems to function as expected:

I get the unmasquerade link in the Admin Toolbar ONLY if I am masquerading, which is how I would expect it to work.

However if I am logged in as any user, masquerading or not, then I ALWAYS get the unmasquerade link in the user account menu.

I have applied the workaround suggested by esod, by removing the link from the user account menu all together, however it would be useful if this worked as expected so when masquerading as a user who doesnt have the admin toolbar I can unmasquerade easily.

The difference between my report and the original report could well be because I am running 8.x-1.0-beta1 on newer core 8.1.2?

Caching-related issues should have been fixed by #2448699: Implement caching for the masquerade block and links with a 'masquerade' cache context. Can you try and reproduce the issue using 8.x-2.x-dev?

Looks we need new release

Same issue here. I'm using Drupal 8.2.3. Eventhough I go to admin/structure/block/manage/masquerade and change the view mode to Admin user. Any authenticated user will se the UnMasquerade button.

Are you sure you're not using UID1 for testing?

I think that this is caused by the missing cache meta-data in the toolbar item. The attached patch fixes it for me.

Is there steps to test it?

+++ b/masquerade.module
@@ -52,9 +52,15 @@ function masquerade_help($route_name, RouteMatchInterface $route_match) {
+        'contexts' => ['session.is_masquerading'],

looks a right way, to provide context always

Works for me! This is great, I ran into this bug in several projects now.

The cache context is the right solution for this.

it still needs test coverage

Do I understand correctly that this fix causes the unmasquerade link to appear only when an administrator with that permission is masquerading (session.is_masquerading) as other user, right? Well I just tested the patch on my Drupal 8.63 and guess what, now the unmasquerade link is removed when I am masquerading as other user. Is that expected behaviour? By accident I was using "Switch user" in stead of Masquerade. I can confirm that the patch works as expected.

Found this too and came up with the same fix.

Note that this is not a problem by default because shortcut.module still makes the toolbar uncacheable in dynamic page cache. Once #2914110: Shortcut hook_toolbar implementation makes all pages uncacheable is committed, this problem will start to appear for a lot more use cases, specifically users that do have access to shortcuts.

Added a test case to check if the cache context is present and if the unmasquerade link is not visible, when you login with a user.

Adding just a test only patch.

+++ b/tests/src/Functional/MasqueradeCacheTest.php
@@ -57,4 +58,26 @@ class MasqueradeCacheTest extends MasqueradeWebTestBase {
+    // Login as admin and masquerade as the test user to have the page cached
+    // as the test user.
+    $this->drupalLogin($this->admin_user);
+    $this->masqueradeAs($test_user);
+
+    // Login as the test user and make sure the Unmasquerade link is not visible
+    // and the cache context is correctly set.
+    $this->drupalLogin($test_user);
+    $this->assertNoLink('Unmasquerade');
+    $this->assertCacheContext('session.is_masquerading');

assertNo* tests are always a bit tricky, because it is for example possible that the label is changing and then it would still pass.

The best way to prevent that is to also add explicit asserts close to it that make sure that link is shown when it should be, aka, just duplicate those two lines and do assertLinke() + cache context after the masquerading as well.

Then once more test-only + combined patch and then it should be RTBC.

Expanded the test as you suggested.

Thanks, looks good now I think.

Remember to upload the test-only patch last because the testbot will update the status based on the last patch in an issue comment.

Thanks a lot for fixing and tests