Double password prompt when playing live event URL

[daniel-frampton-pc]

If a live event URL is passed to the Video.Player constructor, and the event is password-protected, the user is prompted twice for a password.

(This is related to case #28242777.)

Here is the live event URL in question, it belongs to my trial Advanced-tier account; you may need to replace it with your own if/when my trial expires on 11/25/25:
Example live event URL: https://vimeo.com/event/5529829
Password: ilovesmores

Codepen link, with that live event URL hard-coded, where I was able to reproduce as of today (11/20/25, 5pm ET):
https://codepen.io/Daniel-Frampton/pen/zxqEKgG

Note: if I open that Codepen, or our own application, in the same browser in which I am logged in to the Vimeo account that owns the live event, I don't see any password prompts. To reproduce the prompts, I needed to view the Codepen or our application in a different browser or incognito tab.

Browser: Chrome
OS: MacOS

What we're experiencing:

• Admin user creates a Vimeo live event that is password-protected,
• They provide us with the live event URL, which we store.
• User loads our page
• (In our code, we pass the live event URL in as the url option to the player constructor.)
• Player SDK loads
• Player shows "Enter password to watch" prompt, with "Enter password" placeholder text and a "Submit" button (horizontally aligned, black input, black button).
• User enters password and submits it, player briefly shows loading spinner.
• Player shows another password prompt, this time with heading "Password required" and text "If you have access, enter the password to watch", with another text input with "Enter password" placeholder text and "Submit" (vertically aligned, white text input, blue button).
• User enters password again, and the player shows the live event.

The first password screen:

The second password screen:

Browser console logs (Chrome) when the issue occurs in our own application code.

If I use a video URL, where the video is password-protected, instead of an event URL, the user is only prompted once (with the 2nd prompt). So this appears to be limited to event URLs.

Ideal behavior: the user is only prompted for the password once, instead of twice.

Any help is appreciated. Let me know what additional info I can provide.

[jdreetz]

Hey @daniel-frampton-pc, would you mind testing not in Incognito, but logged out of Vimeo? I think this is an issue with cookie blocking in Chrome. I tested your Codepen and it allowed me to access the video by only entering the password once, when I was not in Incognito. When I as in Incognito, I saw the same behavior you described.

[daniel-frampton-pc]

Hey @daniel-frampton-pc, would you mind testing not in Incognito, but logged out of Vimeo? I think this is an issue with cookie blocking in Chrome. I tested your Codepen and it allowed me to access the video by only entering the password once, when I was not in Incognito. When I as in Incognito, I saw the same behavior you described.

Thanks for taking a look @jdreetz! I tried that and saw the same thing as you: I was only prompted for password once (the first of the two in the description) in Chrome when logged out of Vimeo and not in incognito.

Fwiw, decided to check other browsers I have available, confirms it's about cross-site cookies:

• Safari, when "Prevent cross-site tracking" setting is enabled (by default), I see the double password prompt.
• Safari, when that is disabled, I only see the first prompt.
• Firefox, with default settings, I only see the first prompt.
• Firefox, with custom privacy setting configured to block "Cross-site tracking cookies", I see both prompts.

Also fwiw, in our use case, we are rendering our page with the Player SDK in a lot of user contexts, including all major browsers, desktop and mobile, and in a mobile app via React Native Webview, which is the first context where this was reported to us. I'll be looking into how cross-site cookies are handled by it and whether it's configurable, but so far it's seeming to be device- and platform-specific and out of our hands.

So, couple of follow-up questions:

• is this expected and/or intended?
• did something recently change on the player side that introduced this behavior? And if so, so we can pass it along, what was it? (Our users reported it began around a month ago.)
• would you all consider a change that would allow for a single password prompt independent of cross-site cookie settings in the user agent?

Thanks again for considering!

[jdreetz]

Hey @daniel-frampton-pc, thanks for doing that investigation on the different scenarios where this might be an issue!

In answer to your questions:

is this expected and/or intended?
This is expected given the embed's structure and password handling, although we aren't happy about the current behavior.

did something recently change on the player side that introduced this behavior? And if so, so we can pass it along, what was it? (Our users reported it began around a month ago.)

We introduced a change couple weeks ago to fix a rendering issue with this scenario, but it sounds like the issue your users are seeing pre-dates that change? To confirm, did you have password protected Live Events embedded before, that were working as expected on the problem browsers?

would you all consider a change that would allow for a single password prompt independent of cross-site cookie settings in the user agent?

Yes, we are planning on making a change to the embed to make this work better. Timing-wise, we plan to start working on a change some time this month, but no definite timeframe when the change might be released for now.

Let us know if you have any follow-up questions or observations!