Panopto Embed API -- Possible to send additional auth events depending on the session privacy.
Hello everyone --
First and foremost, I hope everyone is having a wonderful day! This is my first time posting anything in the Panopto forums, so I apologize in advance if I don't follow the current standards and conventions. I didn't know whether or not to post this in the API
category, or the Feature Request
category -- since it honestly applies to both.
Anyways, I have an idea for a potential feature request that I believe would benefit the Panopto Embed API greatly, and it has to do with expanding off the authentication event. Currently, as stated in the Panopto Player API docs, it states that the onLoginShown event is raised when the login page is shown in cases where the user needs to be authenticated before accessing the video however if the user is already authenticated, this will not fire.
This works as expected, however, there is a use case that this authentication event doesn't necessarily seem to handle, and I would love to see if we could expand on it.
Currently, if I use a Panopto video within my application that requires authentication to view, i.e it is restricted in some way:
and I authenticate with an account that has the correct viewing permissions to view, this could be the administrator, or a newly created user group that I gave explicit access to, then everything works as expected and I could view the video. The issues arises, and the use case I can't seem to deterministically handle, is when I now try to sign in with an account that doesn't have the correct viewing permissions to view that video -- that could be because I removed that user from the user-group, or explicitly configured that user to not be able to view that video. Whatever the case may be, once I log in with that user I can't view the video in the Panopto Embed player however no helpful events have been raised to capture this. The onIframeReady
event isn't fired, so I can't even hook into that event to somewhat help me out.
Essentially -- would it be possible to pass back a value from the onLoginShow
or even the onReady
event that is fired from the Panopto Embed API to indicate what authentication error has happened or occurring if appliciable? This would in turn, allow us to differentiate the error we are receiving, for instance, if playback is completely blocked, if the video the user is trying to watch doesn't have access to that video (the use case described earlier), or even if the video (session) has been deleted?
It could look something like this:
. . . // The following function creates an <iframe> and Panopto player var embedApi = null; function onPanoptoEmbedApiReady() { embedApi = new EmbedApi('player', { width: '850', height: '650', //This is the URL of your Panopto site serverName: 'serverName', sessionId: 'sessionId', videoParams: { // Optional parameters //interactivity parameter controls if the user sees table of contents, discussions, notes, & in-video search interactivity: 'none', showtitle: false, hideoverlay: false, start: 0, }, events: { onIframeReady: onPanoptoIframeReady, onReady: onPanoptoVideoReady, onStateChange: onPanoptoStateUpdate, onError: onPanoptoError, onLoginShown: onPanoptoLoginShow, }, }); } . . . function onPanoptoLoginShow(eventData) { console.log('auth event fired!'); const { data: authError } = eventData; console.log(authError) switch(authError) { case 'invalid_session': // code to handle break; case 'unauthorized_access': // code to handle break; default: // handle default case break; } } OR // Since this would be needed in order to handle if the user already had a valid authenticated // Panopto session, not logging in through the Panopto Embed API. function onPanoptoVideoReady(eventData) { console.log('player ready event'); const { data: playbackError } = eventData; console.log(playbackError) switch(playbackError) { case 'invalid_session': // code to handle break; case 'unauthorized_access': // code to handle break; default: // handle default case break; } } . . .
Or maybe some new event entirely -- basically any additional info we could use to handle such a case. It doesn't have to look like this at all, just a few thoughts I have.
Any and all thoughts / feedback would be greatly appreciated.
Thank you so much for your time.
Warm regards,
Tyrus Malmtrom.