search

AzureAD / microsoft-authentication-library-for-dotnet

Microsoft Authentication Library (MSAL) for .NET
https://aka.ms/msal-net
MIT License
1.39k stars 342 forks source link

Add 'haschrome=1' to avoid unexpected back buttons on the first page. #4836

Closed fengga closed 2 months ago

fengga commented 2 months ago

https://identitydivision.visualstudio.com/Engineering/_workitems/edit/2972166

Fixes #4738

Changes proposed in this request

It's very easy to reproduce (need to add login hint in the test app code first) the back button by: image

In MSAL C++, interactively calls always add "haschrome=1" to avoid such kind of unexpected back buttons on the first page, and this way is also recommended by ESTS folks. https://github.com/AzureAD/microsoft-authentication-library-for-cpp/blob/4fa774db2b38cdce9c9b94e3e686ab53fc24b948/source/xplat/requests/WebRequestManager.cpp#L566

After adding "haschrome=1" the issue can be resolved: image

Testing

Performance impact

Documentation

bgavrilMS commented 2 months ago

Nice fix @fengga . Just see that a few unit tests need to be updated.

rayluo commented 2 months ago

In MSAL C++, interactively calls always add "haschrome=1" to avoid such kind of unexpected back buttons on the first page, and this way is also recommended by ESTS folks.

Intriguing finding. It feels like folklore because even the name of that workaround - "haschrome" - does not make much sense. :-)

On a more serious note, the current feature branch name is "fixEmbeddedbrowser", however, now I realize that the same mysterious Back-button behavior also applies to Firefox as system browser: it shows up by default, and disappears when using haschrome=1. But I am not aware of other complain, presumably because that default Back button is understandably perceived as a Cancel. So, I suppose we do not have to propagate this change to all other MSALs, do we?