Keep the modal dialog open after browser's refresh click

Hi, I have a modal dialog that is designed to block the user from going forward to the following page until the user read the info on the modal dialog and click on one of the 2 buttons (decline and accept) to either accept or decline in order for the modal to close. If the user decline, it closes the modal dialog and ends the session. If accept, the modal dialog will close and the user would be on the current page. All these things are working fine.

However, if the user clicks on the browser’s reload/refresh, the modal will disappear and the user will be on the current page, meaning the user can by pass this modal dialog to next page by clicking on the browser’s refresh button.

Since the browser’s refresh/reload button is something I cannot control, how can I keep this modal dialog remain open even if the user clicks on the browser’s refresh button?

I created 2 flags in the component. js page of this modal dialog to save the state of the user’s response on either button, and their default value is false. I then created an action to check these 2 flags and set the modal dialog to show if both of the flags is remain false. But I don’t know where to put this action so that it will keep do this check and keep the modal dialog open until the user responds, regardless how many times the user clicked on the browser’s refresh.

I have searched endless on Google, but none seems to have answer for the issue I am dealing with, so any help and inputs you can provide would be greatly appreciated. Thank you.

It seems to me you should just come back in the state before the Model dialog. You can also set a query param to open the dialog like we do here with coupon` on this Ember site:

You could definitely use a query param as @broerse suggests, and that would work great across refreshes. Or you could even do something like a local storage flag indicating that the user has or has not accepted the agreement. These are more or less the same solution, you’re just storing the state in different places.

The problem with these sorts of solutions is that they all rely on “client-side state” so they can all be bypassed in some way. The query param could be bypassed by a user manually manipulating the URL/query param. The local storage solution could be bypassed by a slightly more technical user manipulating the local storage entry. This may be fine for your use case, but if not… the only way to really ensure that the user has performed an action indicating that they agree is to keep server-side state indicating that they agreed (as in presenting the dialog, when they click decline it ends the session, if they click agree it makes a request to the backend and once that request is fulfilled successfully they are allowed to move on). So it depends on your requirements and how “secure” this needs to be.

If it’s ok for a clever user to be able to manually bypass I’d recommend using query params or local storage, otherwise I think you’ll need to use a server side flag.

Thank a lot dknutsen, I think you have a very good point. query param is what broerse also suggessted earlier, but I agree that it too can be changed on the client side. So, I do have the accepted flag that I created to save that to the database and then get it back to confirm that it has saved through the api endpoint, so I will try that. I also found another post yesterday on the net said that there is another option is to use nested routes, and for their application, that was the best solution, because it will keep the modal visible without side effects or condition. I don’t know what all that mean and still trying to wrap my head around that idea because I thought how can that work as it would just pass that issue from one route to another. But I will try to check the server side flag as you have mentioned and even try to add another route and see. Thanks again.

thanks a lot broerse. I don’t quite understand what you mean by come back in the state before the model dialog, and I am looking into query param you suggested. Thanks again.