I'm implementing a 2FA login for a WebDirect solution. The user arrives, provides their username and password, and a 2FA code is sent to them via email. On the desktop this works.
In iOS Safari, when they switch to their email program and return to enter the code into the field WebDirect is unresponsive. It won't allow them to enter data into a field, nor will it allow them to interact with other elements, such as buttons.
The server version is 20.1.2. The browser is Safari (iOS).
I would be careful about how 2FA is implemented. If the user provides username and password to something that is WebDirect, if they are not logged-in yet, you won't be able to detect the login attempt to send an email. If they provide the username and password to something because they are logged-in as guest or something similar, they technically already have access to your system, and that can be a security hole.
There are criterias to meet for something to qualify as 2FA. You did not share enough for me to make a determination on your specific implementation.
I would favor a 2FA implementation that relies on external authentication. Keycloak can do this, alongside the other benefits external authentication has.
For those who would like to read an interesting discussion on ersatz logins, you can do so here.
Getting back to your issue, perhaps it is not specific to your process, but rather could be a limitation or a bug in how WebDirect behaves on the iOS version of Safari (switching apps seems to be part of the issue).
I would be curious to know if the issue remains if you were to put the browser and the email client on the same screen (assuming this is on an iPad where you can combine apps on a single split view).
The issue has something to do with the length of time it takes Safari to put the websocket to sleep. If I switch away momentarily and switch back the connection remains alive. However, it the few seconds it takes to switch to mail, read the code and switch back, the connection is lost.
Chrome browser happily keeps the websocket connection alive but Safari is the default browser on iOS. [Edit] Yesterday when I tested with Chrome the connection survived. This morning when I took a bit longer to get the 2FA code the connection died.
I've also been informed that Apple requires all the browsers to be Webkit under the hood ( ?? )
If memory serves, iOS puts apps to sleep fast to reduce background processes. iOS really wants to avoid too much activity in the background. This is part of its power management strategy. Apps must ask to remain awake in the background and there are many strategies here too: delayed sleep; periodically wake up; wake up on signal; etc. There are ways for websites to request this too, though I think options are more limited. I am guessing that WebDirect doesn't do this.
Is the behavior the same with Safari on desktop? What about Accessing the same URL in a chrome browser for iOS? (simply trying to narrow down where this is coming from, not suggesting you tell your users to switch browsers).
It’s fine on the desk top.
Interruptions are normal for web traffic, and mixing web browsing with a phone call or a message has to be expected on an iPhone. I wonder if it’s a recent development?
Not on the part of iOS. The power saving strategy was once derided until battery life became important.
iOS applications are expected to handle the interruptions, not the OS. Same goes for web pages. Soooo… Claris would need to resolve this in WebDirect?
I'll note that I am not suggesting the following as production workarounds, but I would be curious if having some periodic action would keep the page from losing its active status.
What comes to mind:
There is already an on timer script running. Waiting for user response.
Ignoring the web page until iOS sleepers causes the normal alert messages which allows the user to recover. In this case there is no interaction possible. The page is unresponsive.
We've just had a fairy tell us that the problem will only occur when the user is editing a record. In our case, we were setting the cursor into a field anticipate the user entering their 2FA code.
When the record is closed there is no problem switching between applications and returning.
Fascinating. Thank you for this update, and kudos to the fairy.