Fix web session playback when a duration is not provided#50262
Merged
Conversation
zmb3
commented
Dec 15, 2024
zmb3
force-pushed
the
zmb3/playback-url
branch
3 times, most recently
from
dcc3a91 to
9277557
Compare
gzdunek
approved these changes
Dec 16, 2024
Contributor
gzdunek
left a comment
gzdunek
left a comment
There was a problem hiding this comment.
I left some minor comments on the JS code.
zmb3
force-pushed
the
zmb3/playback-url
branch
2 times, most recently
from
ab190f5 to
4d0c90d
Compare
github-actions
Bot
added
audit-log
zmb3
force-pushed
the
zmb3/playback-url
branch
2 times, most recently
from
7c3e151 to
1b290e1
Compare
rudream
approved these changes
Dec 18, 2024
rosstimothy
approved these changes
Dec 18, 2024
public-teleport-github-review-bot
Bot
removed the request for review
from avatus
Prior to Teleport 15, the web UI would download the entire session recording into browser memory before playing it back (crashing the browser tab for long sessions). Starting with Teleport 15, session playback is streamed to the browser and played back as it is received instead of waiting for the entire session to be available. A side effect of this change is that the browser needs to know the length of the session in order to render the progress bar during playback. Since the browser starts playing the session before it has received all of it, we started providing the length of the session via a URL query parameter. Some users have grown accustomed to being able to access session recordings at their original URLs (without the duration query parameter). If you attempt to play recordings from these URLs after upgrading to v15, you'll get an error that the duration is missing. To fix this, the web UI needs to request the duration of the session before it can begin playing it (unless the duration is provided via the URL). There are two ways we could get this information: 1. By querying Teleport's audit log 2. By reading the recording twice: once to get to the end event and compute the duration, and a second time to actually play it back. Since we only have a session ID, an audit log query would be inefficient - we have no idea when the session occurred, so we'd have to search from the beginning of time. (This could be resolved by using a UUIDv7 for session IDs, but Teleport uses UUIDv4 today). For this reason, we elect option 2. This commit creates a new web API endpoint that will fetch a session recording file and scan through it in the same way that streaming is done, but instaed of streaming the data through a websocket it simply reads through to the end to compute the session length. The benefit of this approach is that it will generally be faster than option 1 (unless the session is very long), and it effectively pre-downloads the recording file on the Note: option 2 is not without its drawbacks - since the web UI is making two requests that both read the session recording, the audit log will show two separate session_recording.access events. This isn't ideal but it is good enough to get playback working again for customers who don't access playbacks by clicking the "Play" button in the UI.
zmb3
force-pushed
the
zmb3/playback-url
branch
from
1b290e1 to
c4bdb8c
Compare
This was referenced Dec 19, 2024
carloscastrojumo
pushed a commit
to carloscastrojumo/teleport
that referenced
this pull request
Feb 19, 2025
…al#50262) Prior to Teleport 15, the web UI would download the entire session recording into browser memory before playing it back (crashing the browser tab for long sessions). Starting with Teleport 15, session playback is streamed to the browser and played back as it is received instead of waiting for the entire session to be available. A side effect of this change is that the browser needs to know the length of the session in order to render the progress bar during playback. Since the browser starts playing the session before it has received all of it, we started providing the length of the session via a URL query parameter. Some users have grown accustomed to being able to access session recordings at their original URLs (without the duration query parameter). If you attempt to play recordings from these URLs after upgrading to v15, you'll get an error that the duration is missing. To fix this, the web UI needs to request the duration of the session before it can begin playing it (unless the duration is provided via the URL). There are two ways we could get this information: 1. By querying Teleport's audit log 2. By reading the recording twice: once to get to the end event and compute the duration, and a second time to actually play it back. Since we only have a session ID, an audit log query would be inefficient - we have no idea when the session occurred, so we'd have to search from the beginning of time. (This could be resolved by using a UUIDv7 for session IDs, but Teleport uses UUIDv4 today). For this reason, we elect option 2. This commit creates a new web API endpoint that will fetch a session recording file and scan through it in the same way that streaming is done, but instaed of streaming the data through a websocket it simply reads through to the end to compute the session length. The benefit of this approach is that it will generally be faster than option 1 (unless the session is very long), and it effectively pre-downloads the recording file on the Note: option 2 is not without its drawbacks - since the web UI is making two requests that both read the session recording, the audit log will show two separate session_recording.access events. This isn't ideal but it is good enough to get playback working again for customers who don't access playbacks by clicking the "Play" button in the UI.
zmb3
added a commit
that referenced
this pull request
Jun 25, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
zmb3
added a commit
that referenced
this pull request
Aug 7, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 7, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
backport-bot-workflows Bot
pushed a commit
that referenced
this pull request
Aug 7, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
backport-bot-workflows Bot
pushed a commit
that referenced
this pull request
Aug 7, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
backport-bot-workflows Bot
pushed a commit
that referenced
this pull request
Aug 7, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 7, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 8, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 8, 2025
In #50262, we made it so that the "durationMs" query paramater in the session player URL is optional (at the expense of an extra API call to determine the recording length prior to playback). We did not, however, do the same for the "recordingType" parameter. This commit adds that information to the existing API call. As a result, users who want to build playback URLs directly instead of clicking the play button in the UI have a stable URL format that will play the session. Closes #55780 Closes gravitational/customer-sensitive-requests#472
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prior to Teleport 15, the web UI would download the entire session recording into browser memory before playing it back (crashing the browser tab for long sessions).
Starting with Teleport 15, session playback is streamed to the browser and played back as it is received instead of waiting for the entire session to be available.
A side effect of this change is that the browser needs to know the length of the session in order to render the progress bar during playback. Since the browser starts playing the session before it has received all of it, we started providing the length of the session via a URL query parameter.
Some users have grown accustomed to being able to access session recordings at their original URLs (without the duration query parameter). If you attempt to play recordings from these URLs after upgrading to v15, you'll get an error that the duration is missing.
To fix this, the web UI needs to request the duration of the session before it can begin playing it (unless the duration is provided via the URL). There are two ways we could get this information:
Since we only have a session ID, an audit log query would be inefficient - we have no idea when the session occurred, so we'd have to search from the beginning of time. (This could be resolved by using a UUIDv7 for session IDs, but Teleport uses UUIDv4 today).
For this reason, we elect option 2. This commit creates a new web API endpoint that will fetch a session recording file and scan through it in the same way that streaming is done, but instaed of streaming the data through a websocket it simply reads through to the end to compute the session length. The benefit of this approach is that it will generally be faster than option 1 (unless the session is very long), and it effectively pre-downloads the recording file on the
Note: option 2 is not without its drawbacks - since the web UI is making two requests that both read the session recording, the audit log will show two separate session_recording.access events. This isn't ideal but it is good enough to get playback working again for customers who don't access playbacks by clicking the "Play" button in the UI.
Changelog: Restore the ability to play session recordings in the web UI without specifying the session duration in the URL.