Username passed to the SDK not taken into account after 1st session on the same meeting


I’m using the Web SDK (v1.9.1), and I am passing the mandatory userName field to the ZoomMtg.join() function.
It is taken into account the first time I’m starting a Zoom session on the browser, but if I refresh the page and give another userName to the function, while joining the same meeting again, it’s still the very first one that appears in the Zoom meeting, both for myself and for the other participants.

If I flush all the browser’s cache (cookies, localStorage, etc) and refresh the page again, the userName I pass is successfully used by Zoom again, and then the same issue happens again - whatever I do, it will always be this very first userName that will be used by Zoom for this meeting, which will ignore the new value I pass to the ZoomMtg.join() function.

I reckon that the Zoom Web SDK is keeping a cached version of the userName for every meeting (or the last one, at least), and will always use this cached value when it’s set.
But it’s not handy from a developer’s point of view - I cannot even check if there is a cached value and not ask my own users to fill their username, as I don’t have access to the Zoom Web SDK cache storage from my own JavaScript code.
I haven’t found a function in the SDK that would allow me to check that the meeting was already joined, and with which username?

After a first session using the Zoom Web SDK, the username used by the SDK is always the one that was set for this first time the meeting was joined, whatever new userName value I pass to the ZoomMtg.join() function.

Which Web Client SDK version?

To Reproduce(If applicable)
Steps to reproduce the behavior:

  1. Join a meeting using the ZoomMtg.join() function.
  2. After having joined the meeting, refresh the page
  3. Join the same meeting again, using the ZoomMtg.join() function, with another userName.
  4. The user is still displayed with the previous username

If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

  • Device: laptop
  • OS: Ubuntu 20.04
  • Browser: Chromium
  • Browser Version: 90.0.4430.212 (Official Build) snap (64-bit)

Additional context
Note that the value of the userName we give to the ZoomMtg.join() function is correctly taken into account when joining another meeting.

Hey @rougemine,

Thank you for reaching out to the Zoom Developer Forum. It sounds like what’s happening is that the Web SDK is connecting to the original meeting connection when you refresh the page. This would be consistent with behavior I’ve seen with the Web SDK.

If you wanted to change the name of a user, you would either want to leave and rejoin the meeting with a different user name, rename yourself through the UI or use the rename() function from the Web SDK.

Let me know if that helps.


Hi Max.

Leaving and rejoining the meeting does not work. The issue is still reproducible. Even if we pass a new user while rejoining the meeting, the old username is taken. This might be because of values in browser cache taking higher precedence.

The same is happening for removed users. Suppose the meeting host, removes a user, that user’s details are stored in browser’s cache. If I try to join the meeting as another new user, its not allowing this new user to join.

Hey @priyavarshini.muruga,

Thanks for clarifying. Do you see this same behavior when you test with our Sample Web App?


I am seeing behavior like this as well in my testing. The JS values that are being sent to the init function are correct, but its showing the username of another account that was previously testing with. I am seeing this issue in Safari. I have not been able to test yet in Chrome, but I will add any findings on that front if I run into anything.

@ezzman @priyavarshini.muruga @rougemine

I would first try upgrading to the latest version of the Web SDK (1.9.5). Let us know if you see the same issue with the latest version when testing with the Sample Web App.


I tried with the Sample Web App with SDK 1.9.5. I removed the fields and hardcoded the meetingConfigs. The session and local storage values remain the same even after leaving the meeting. I have attached the files in order.

One question - Does the key always start with ZW or ZM ? This way we can differentiate and remove them from our side if the fix is not coming soon…

Yes. Same behaviour is observed in sample app with sdk 1.9.0 and 1.9.5.

Hey @priyavarshini.muruga,

Thank you for providing detailed information. This does seem like a bug.

I’ll test this out further on my end and work with our engineering team to address the bug and confirm if you can rely on the first few characters of that key as a workaround.


Hey @priyavarshini.muruga,

I’m reaching out to let you know I haven’t forgotten about this. I’m still investigating and will report back as soon as I can.


Thank you @MaxM , that’s very much appreciated! :blush:

Hey @rougemine,

Thanks for your patience. I was able to reproduce this behavior and from what I can tell this is intentional to prevent a single user from joining a meeting multiple times.

I’ve reached out to our engineering team to see if they can provide insight (ZOOM-282537).

I’ll get back to you ASAP


1 Like

@rougemine @priyavarshini.muruga

Thanks for your patience. Our engineering team got back to me and confirmed this is expected behavior and that they key being used is dynamic. They offered the following method as a potential solution:

Let me know if that helps.


@MaxM If a user joins a meeting with one username, they will not be allowed to join some other meeting with a different username from the same browser until the session expires. Is this the expected behaviour ?

The use case that we are trying to solve : We have a website with authentication. Login name is used as display name while joining the zoom meeting. For logged out users, we generate a random username. If a user joins a meeting as logged out user, leaves the meeting and rejoins as logged in user, the login name should be displayed instead of randomly generated name. Currently this is not achievable due to session storage value.

And we have several session storage items other than zoom related items and we don’t want to clear them all.

Are there any other alternatives to achieve this ?

Hey @priyavarshini.muruga,

Yes, our engineering team confirmed this is because they attempt to use the name stored with the session first.

If you have your own keys that you don’t want to remove, you can clear the remaining keys using process of elimination. A good process might be to have a prefix on your keys and then iterate through all the keys and clear what isn’t needed.

Here’s a quick example of iterating the keys:

My apologies that we don’t have a better method, I think we definitely need a way to clear the cache manually. If you would like this feature to be considered for a future release, I recommend posting in the #feature-requests category.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.