cancel
Showing results for 
Search instead for 
Did you mean: 

Another problem with embedded passcodes

JS_SilverSpring
Explorer
Explorer

Yesterday, I encountered a problem similar to the one reported by FPCOfficeMgr.

Person A and Person B were both registered users for a Zoom meeting. The host of the meeting sent a link with the passcode embedded. But Person B didn’t receive the email, so he asked Person A to forward the email with the link. However, on the day of the meeting, Person B’s computer was broken so he logged on to his email account using Person C’s computer. But when Person B clicked on the link via Person C’s computer, he was asked for a passcode even though the passcode was embedded in the link. The Zoom meeting had already started, so Person A was able to ask the host for the passcode, but none of us could figure out why that happened. Can you provide an explanation? Thanks.  

1 ACCEPTED SOLUTION

Ray_Harwood
Community Champion | Customer
Community Champion | Customer

Correct: a confirmed login drops the cookie with date and time, plus the user’s login (not sure whether it uses email address, customer number, or something else). Multiple users on one computer are handled distinctly. 


Ray -- Happy holidays, everyone! I’m taking a few days (mostly) off. See you in 2025!

View solution in original post

3 REPLIES 3

Ray_Harwood
Community Champion | Customer
Community Champion | Customer

Welcome to the Zoom Community, @JS_SilverSpring.


It’s unclear to me whether you are referring to the Passcode (required to enter a meeting) or a 6-digit verification code sent vis email (to authenticate your login from a new machine or browser). If you’re referring to the 6-digit via email authentication step, please see my answer on this thread:

https://community.zoom.com/t5/Meetings/embedded-passcodes/td-p/161150 

 

But assuming you are talking about the Passcode issue, here’s my thoughts:


In my opinion, this situation only has three possible causes:

  1. The meeting didn’t originally have a Passcode, and one was added.
  2. The meeting’s passcode was changed after the original message was sent out.
  3. The URL was not copied and forwarded in full, or was altered (likely inadvertently) along the way. 

The password encoding process works correctly millions of times every day. Every instance of it “not working” that I have been able to investigate thoroughly has been confirmed to be from one of those three causes. 


Ray -- Happy holidays, everyone! I’m taking a few days (mostly) off. See you in 2025!

JS_SilverSpring
Explorer
Explorer

It was definitely the passcode. because the link had the passcode embedded in it, and when Person B was asked for the passcode, the Zoom host provided it, Person B entered it on his computer, and was able to join the meeting. 

But on reading the information that you referred to in the link that you included in your response to my email, I'm guessing that this is the important part:

A confirmed login results in a browser cookie run store, identifying the user’s successful login in that machine

It appears that the cookie identifies both the user and the user's machine. So even though both Person B and Person C had used Zoom successfully many times in the past, this would probably have been the first time that Person B logged on to his email using Person C's computer.

Does that sound like a reasonable interpretation?

 

 

Ray_Harwood
Community Champion | Customer
Community Champion | Customer

Correct: a confirmed login drops the cookie with date and time, plus the user’s login (not sure whether it uses email address, customer number, or something else). Multiple users on one computer are handled distinctly. 


Ray -- Happy holidays, everyone! I’m taking a few days (mostly) off. See you in 2025!