Leaked Metadata After Cache Rebuild

@$^@%#%$$%@$%#$%#$ cacheability metadata and URLs...

(At least digesting all the discussion around it in the past month, got me to a point where I'm not despairing after your bug report.)

So... I can't reproduce this.

1)
First things first: I discovered an error in the code while typing up this answer. Does making the following (temporary) change help?

diff --git a/src/EventSubscriber/AccessDeniedSubscriber.php b/src/EventSubscriber/AccessDeniedSubscriber.php
index 9f3202a..b4c36b2 100644
--- a/src/EventSubscriber/AccessDeniedSubscriber.php
+++ b/src/EventSubscriber/AccessDeniedSubscriber.php
@@ -47,7 +47,7 @@ class AccessDeniedSubscriber implements EventSubscriberInterface {
         case 'samlauth.saml_controller_login':
         case 'samlauth.saml_controller_acs':
           // Redirect an authenticated user to the profile page.
-          $url = Url::fromRoute('entity.user.canonical', ['user' => $this->account->id()])->toString();
+          $url = Url::fromRoute('entity.user.canonical', ['user' => $this->account->id()])->toString(TRUE)->getGeneratedUrl();
           $event->setResponse(new LocalRedirectResponse($url));
       }
     }

2) If that's not it:

From all I know right now, this is not directly an issue with the code in the samlauth module (although it is possible for the samlauth module to take measures to prevent it). I instead suspect code that is executed on an event or a hook that is called by /saml/acs.

So:

• Do you have any code (custom module, likely) on the 'USER_SYNC' event subscriber? (Does it call Url::toString()?) Can you disable it and test if you still get the exception?
• Do you have a "Login redirect URL" configured? Does it contain a token?
• Any contrib/custom modules that you know execute code during saving the user (when its properties are synchronized)? Can you shut them off and test if you still get the exception?

If a cause can be pinpointed, I'd love to know, because I want to dive into this URL/Leaked Metadata mess.

3)
Regardless, I'll have a patch soonish. First attempt failed, so I'll need to do a little more work (hopefully) tomorrow.

Thank you nicolas-mosch.

Looking at the bug in the LDAP/user module code yourself is optional, because samlauth likely can and should prevent the LDAP/user module from having this effect.

I personally still want to check out their code and see if a bug report should be filed, because I spent some time trying to work out the depth of the problem surrounding this "Leaked metadata" exception in detail, and this is a practical example where I can verify practical obstacles.

But if you really want to know:

• You're likely looking at a Url::toString() call; those are 'magic' and do stuff in the background which may cause the exception in the end.
• It's not only Url::toString() which can have this effect but this is very often the
• The hunt for the magic behavior is described best in https://www.lullabot.com/articles/early-rendering-a-lesson-in-debugging-...
• The reason why Core implemented this magic is hinted at, in a response from Wim Leers to that same article, and in #2450993-107: Rendered Cache Metadata created during the main controller request gets lost until 133 (and #2638686: Correctly handle cache data instead of throwing an Exception in EarlyRenderingControllerWrapperSubscriber()), but it's not an easy read.
• I have proposed an way-too-long extension to the docblock of Url::toString() (because I'm concerned we are not telling developers about the dangerous magic), in the interdiff attached to #2735575-66: Make Url::toString(TRUE) explicit by having a Url::generate() method, as well as having GeneratedUrl::toString

Fixing the samlauth module to work around the dangers, will be easier than reading all this. I just need time to sit down and continue, one of these evenings.

Well, that took longer than I hoped... Had another half year break on working on this module.

I've now decided which way I want to solve this, and pushed a fix to the 3.x-dev branch.

What you can also do, instead of using this -dev branch, is try to apply #3092008: Possible fix to "leaked metadata" exception to the ldap_user module, and see if the issue goes away. Because I've uploaded a patch for what I think is the code causing the exception, but haven't tested it. So I don't know if it's complete.

Since there have been no further reports about leaked metadata, I'll assume (admittedly for the third time) that the code is now handling all possible situations correctly.