As a compliance officer, I would like to know if the user is still active within the session so that I do not automatically log them out.
GIVEN the user is active in a trusted extension directly to the related tab
WHEN the user has activity in the trusted extension
THEN the related tab can listen for that activity and keep the session alive
Send the initiating tab a message when the user is interacting with the form.
Hey @Josh_McKenney , interesting feature request! (I think it's understood but to call it out explicitly...) You operate the website from where the form was triggered.
So, in your post, there is the use case (know if the user is still active within the session while using the form window) and also a proposed solution (send the initiating tab a message when the user). I would prefer to implement this use case in a way that would be pluggable into any website. First, let's look at all the possible options we have (and I'll also elaborate on your suggestion).
Important note: None of what I suggest below is implemented right now (and may not be implemented). I'm just brainstorming the possible solutions here.
Brief: On every form data update, dispatch a message/event to the website script.
Explanation: We'll need to use window.postMessage (the chrome.* APIs cannot send a message from an extension to a website). Note that arbitrary postMessages can cause websites to break (because they weren't expecting them), so it is important that we only send this message when the website opts in to those messages first. To establish this 'opt-in', the website could send a predetermined message to our extension.
Challenge 1: right now, we have a static configuration that restricts external message abillity to only ["https://*.blaze.today/*", "https://blaze.today/*"]. I think it is unlikely we would change that anytime soon.
Solution to challenge 1: the website could dispatch a postMessage/CustomEvent first, with a unique key like __TB__form_optin, which our extension script can listen for. Once we receive this message, then we know it is okay to dispatch the form data updates to the specific website for that session.
This is the official approach for website<>extension communication in Firefox. Again, in general, we would lock down external messages to Blaze domains, but because these dispatches are runtime behaviour, we can expose certain unique message keys like these for all websites.
Brief: have the website ping our extension every X ms to check if there was a form data update in the past X ms.
Challenge 1: same as the model above and also has a similar solution
Challenge 2: I think it would be simpler for us (from Text Blaze side) to just dispatch the event and let the website handle it the way they wish to (which also gives more freedom to the recipient website). So, I would lean towards event model more (over this polling model).
Brief: update a unique row in a table with the latest timestamp of when the user interacted with the form.
Explanation: Every time the user updates a value in the form, we could {dbupdate} a unique row in a table in Data Blaze with the current timestamp. Your website can then read the timestamp in that row, and then it can decide whether enough time has passed since the last update.
Challenge 1: how to find the unique row? I think the tuple of [{user:email}, {site:url}, {snippet:id}, {time: YYYY-MM-DD}] should be enough to uniquely identify the currently active session, but let me know if that's not the case.
If anybody else has any other out of the box ideas, feel free to suggest.
I prefer model 3 because a). it unlocks more use cases than what you asked for, b) you have more flexibility in how you want to set it up (for example, only trigger the updates for certain users/on certain days/for certain snippets/etc.), and c) we wouldn't need to change the extension security model for external website messages.
Let me know what you think.
Preference towards 1 because it requires no backend in the middle. We have logic on the browser side that needs to be notified to "keep alive" and setting up realtime notifications from the backend to the client side is not ideal for us.
Polling could work for us since we're offloading that work to the browser.
requires us to have the backend in the middle