search

lithnet / resourcemanagement-ui-userverification

User verification module for FIM2010/MIM2016
MIT License
2 stars 0 forks source link

"Close" button does not work after sending message #4

Open DaneRainbird opened 3 years ago

DaneRainbird commented 3 years ago

Overview

In the latest build of Chrome [88.0.4324.104 (Official Build) (64-bit) (cohort: Stable)], after sending a text message to the client, the "close" button no longer closes the tab, and will instead reload the page.

Steps to replicate

Thoughts

This seems to be due to the way the ClosePage() function is handled in Verify.aspx:

open(location, '_self').close();
return false;

This method of closing tabs (self redirection) has been considered hacky since at least Chrome 36.0.1985.125, if this StackOverflow post is to be believed, but seems to only now have broken.

This doesn't seem to affect Firefox, oddly enough.

ryannewington commented 3 years ago

Hi Dane,

Thanks for reporting this one. I can reproduce this issue on the latest Chrome build. It looks like there really isnt a way to do this, given we dont have control of the page opening process (handled by FIM).

I think the most sensible thing to do is remove the close button so people dont get confused by unexpected behaviour, and let people close the tab manually when they are done.

Thoughts?

DaneRainbird commented 3 years ago

Hi Ryan,

Seems like the most reasonable option. The only other thing I can think of doing is redirecting to another page, such as FIM's homepage, when the button is pressed.

Since self-redirection still works in Firefox, you could perhaps check the UA string for users connecting from Firefox? Something similar to the below:

<body onload="checkUA()">
     ... body contents here ...
</body>
<script>
    function checkUA() {
        let uastring = navigator.userAgent;
        if (uastring.includes("Firefox")) {
            document.body.append("Running Firefox.")
        }
    }
</script>

That way, the close button could be appended programmatically to the page if the user is still running Firefox.

ryannewington commented 3 years ago

Yeah I had a similar thought, but then we have to keep track of which browsers support it and which dont. Give we are trying to do something that seems to be against what the browsers are allowing, I think its best just to kill it off and let people close the tab. Ideally, FIM would allow us to render inside the portal itself and we wouldnt have this issue!!! 😠

DaneRainbird commented 3 years ago

Yeah, having a list of "supported" browsers is probably too much hassle; killing it off solves the problem and means we don't have to revist later on if Firefox decides to change their security settings (plus, I presume that privacy.resistFingerpinting probably breaks it anyways...)

If you're going to kill it off, it's worth noting that this also affects the MFA management and password reset modules, as both of them use the same layout as this.