I have a web app where I have a multi step registration process done in LiveView…
It was working great until recently where some iOS users are complaining about the process being broken.
The problem occurs at one step when the app is sending a one time verification code. When the user switch to his email app/client to check for the code and come back to the web app the LiveView reload and the process go back to the first step…
I tested on an iOS device (quite old iPhone 7 but with iOS 15.1) and the problem happens either with safari or chrome.
On my Android phone everything is still fine.
I’m currently unable to check for the servers log and I know that without much information it could be difficult to tell anything but I want to know what could cause this problem?
I remember that I already hear about LiveView disconnecting on some devices but I have no more clue.
Thank you very much for any direction…
This may be the iOS disconnecting all web sockets when on background to save energy. The solution is to make sure the app can go back to that step even on reload. On a two step authentication, I usually store the success of every step in the session.
Thanks José for your time!
I was thinking if I need to persist the step (basically the email/code couple) on the database which will need to make a migration/schema/etc. altogether…
But using the session is actually the correct way I guess…
I’ll try to look how to do it… I forget how read/write from the session
Unless it’s just a matter of storing assigns in the
conn rather than the
I think you should create LiveView app so that it can handle WebSocket disconnects anywhere in the app. Otherwise users will have bad experience when WebSocket disconnects and it will happen for some users for sure.
Not quite, there is put_session in the
conn. If you are using LiveView, the trick is to use
phx-trigger-action to submit a page where you then validate the credentials/form and persist to the session.
I agree with that, I’ll try to read and learn more about that pattern… We can check for when the WebSocket is connected with
connected? but is there a way to check for disconnection in the server side?
Oh, yes, simply that of course…
I didn’t hear about phx-trigger-action
But since (I quote from here):
phx-trigger-action is true, LiveView disconnects and then submits the form.
Isn’t this will explicitly switch back to HTTP reload rather than LiveView refresh?
The LV will die on disconnect, you can probably pubsub to something to see the event or write a
hande_info() callback and try to save some kind of recovery data to the server then but it is probably preferable to encode your recovery data into the browser and either use:
In any case, careful that you sanitise the data coming back. Your form will be easily editable, the session can be made more tamper resistant. You also don’t have to encode “user_id=1” into the form, you could encode the data similarly to how Fly talks about using the session.
liveSocket.disconnect() and then
liveSocket.connect() from browser console.
Another important thing is that LiveView is designed so that it can connect to a different server on reconnect. So if you connected to server A in your first LV session then get a disconnect then reconnect you could connect to server B. There aren’t any problems with this because important state is coming from the browser on reconnect.
We have the same problem, but for us it’s on a page with an payment-iframe that we don’t control.
On the payment page we load the payment iframe.
- The user fills out the payment and presses the pay button
- The payment is authorized at the bank
- The user is required to verify with 3D Secure (which for many people opens an app)
- When done verifying in the app, the user returns to the browser and the browser reloads and loses the chance for the callback from the payment iframe.
I’m not coding this, and I haven’t been a big part of the bug-hunting, so I might have missed a step, but this should describe the key problem. The page reloads while we’re waiting for a callback.
As a “quick” solution we’ve moved to a static page on the payment page, but it just feels wrong. We chose LiveView for a reason, and we want to stick to it, but we can’t see a way out of this.
I’ve witnessed some of the same behaviour on mobile. Most of the time there has been a phx-auto-recover which allows the state to be populated, but occasionally, there is a full page refresh. I haven’t figured out how to deal with it in general, but billing pages should probably be treated more carefully.
For pages such as billing, there are a few options:
- Store the state of the user in ETS with the user-identity stored as a cookie clientside. Need to be careful storing anything more client-side as that can be manipulated for billing which may end up being an issue. On liveview mount, you can check for the state and do the appropriate action.
- Use a static page. I don’t think this feels wrong at all. For instance, for login and pricing pages, I’m not using liveview. I don’t like any user state to manipulated by JS, so it is in a signed https-only cookie which can only be set thru server headers. I did attempt to use liveview initially, but after some thought, it was pointless.