You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the socket that allows real-time updates on the Queue verifies user authentication using the stored JWT token, which is only present if the user authenticates through Shibboleth. This prevents other services (e.g. apps, etc.) from getting real-time information such as the queue status without regularly polling the Queue's other APIs.
The text was updated successfully, but these errors were encountered:
There were a few ideas that I had considered which I believe would beneift from real-time information:
An interactive display board showing the current queue status - polling would work fine but introduces additional complexity in identifying the changes between each poll.
A native queue app for course staff to interact with the queue more easily on mobile devices - polling would probably not work well unless on a very short interval, or it could potentially lead to multiple staff attempting to answer the same question or similar issues.
I think that it may be better to bring up a WebView to handle Shibboleth authentication in the latter case and use the real-time socket as normal, but I'm not sure what the best strategy to work around the lack of real-time information for the first case.
Currently, the socket that allows real-time updates on the Queue verifies user authentication using the stored JWT token, which is only present if the user authenticates through Shibboleth. This prevents other services (e.g. apps, etc.) from getting real-time information such as the queue status without regularly polling the Queue's other APIs.
The text was updated successfully, but these errors were encountered: