Can you tell us more about these "some sophisticated use cases"?

Can you tell us more about these "some sophisticated use cases"?

I wish I could reveal part of the code but it breaches my client's NDA, I have two different form authenticators on one route and there are many constraints and business logic behind the scene.

At some point I decided to rely on the "AuthenticationUtils" response when trying to retrieve the LastUsername value, after#42513 returning null values caused the code break at AuthenticationUtils.php.

I found that the code tries to return blank string if the attribute doesn't exist in the session's attribute bag but it returns null value when the attribute was found with null value set. My PR suggests to convert probable null value to blank string before returning the LastUsername attribute.

I hope that explains the issue better.

Do you write the value into the session yourself? Otherwise I fail to see hownull values could end up there.

Do you write the value into the session yourself? Otherwise I fail to see hownull values could end up there.

I can check that, but IMAO the AuthenticationUtils is supposed to return a cleansed string value no matter what was found in session attribute bag, it should be either the last username in string or blank string, am I wrong?

Do you write the value into the session yourself? Otherwise I fail to see hownull values could end up there.

checked that, yea, I collect a few more credential details and post them all to the app for authentication, so yep, I put it into session.

Instead of writingnull to the session, I would remove the attribute from the session instead. Or, if I'm fully honest, I would advise to not write custom values to this attribute at all.

Attributes starting with an underscore - like_security.last_username - are meant for internal usage in Symfony. They are not meant to be written to outside the Symfony core, and are likely to cause more issues like this one.

I'm going to close for the reason given by Wouter above. Thanks for proposing,@sarbanha

Thank you all for your comments.

I am going to ask to re-open this PR after closer review of my code and the communicated comments in here,
I have to correct my previous comment about storing attributes in_security.xxx attribute bag. I don't store any extra value in the security session.

One of my authenticators is OTP authenticator and doesn't have username field in the POST request, there are mobile number and OTP code plus csrf, when symfony starts the authentication process it internally adds_security.last_username=null

I believe Symfony authentication mechanism looks for the username value to store in the_security.last_username .

This issue doesn't have any negative effect on the normal operation of web application since we don't usually enumerate the_security.xxxx values manually. But, it breaks the Symfony Profiler while retrieving list the session attributes.

I believe there are two workarounds for this issue, first is that Core Authentication ignores to add_security.last_username to the attribute bag of the session, second is to update the AuthenticationUtils to return coalesced value of LastUsername as this PR suggests.

@chalasr

when symfony starts the authentication process it internally adds _security.last_username=null

Can you point out the code doing that?

when symfony starts the authentication process it internally adds _security.last_username=null

Can you point out the code doing that?

I traced the issue, couldn't find it, it's weird! I will check the code deeper to figure out why this happens, if I found any clue, I will reply here