I don’t know where to drop this, there’s no category for “web portal”. I have two accounts; one successfully stays logged into zoom.us across browser exit/restarts, and the other absolutely refuses to no matter what I do, clear, reset, etc. My bookmark for both is zoom.us/meeting just to jump to a known point. I’m the ONLY user of the accounts, and am not trying to bring multiple “devices” in at once. This is done via different desktop browser profiles, which are basically identical. “Stay signed in” is always checked on the sign-in screens.
My question is this: where is the login state stored? Cookies? Local app storage? Some hidden attribute about the account(s) in Zoom’s database? What can I clear to definitively “start over” on the problematic account and make it work as it supposedly should? This is super-frustrating, as noted in many other forums. help me dig in and debug what’s going on (or not).
Don’t blow off this issue, it’s making customers look hard at GMeet, skype, and even Teams as alternatives that don’t mess with them like this. If this was the wrong place to post this, please move it appropriately.
It was like pulling teeth and took two weeks of back-and-forth and escalation, but I finally got an answer to this. First of all, you have to allow traffic and script execution to some piece of sketchiness called “cookielaw . org”, to which Zoom has apparently outsourced all their cookie management instead of keeping it in-house like they should have. Then, you have to go waaaaay down at the bottom of most Zoom portal screens, and the tiny final item on the last line you see is “cookie settings”. That pops up a configuration widget that needs access to cookielaw. org to work.
In that, you must at a minimum have “functional cookies” turned on, in addition to the “strictly necessary” ones. Then, Zoom will be able to set a cookie called “zm_kms” upon signing in, which is the magic “keep me signed-in” cookie that remembers your login state across browser runs.
Once that preference is set, Zoom also sets another cookie called “OnetrustActiveGroups”, containing a value of “C0003C0001” if you have “strictly necessary” + “functional” classes of cookies enabled. Without that, it reverts to only “C0001”, zm_kms gets UNSET at the next transaction and poof, you’re signed out again after exiting the browser.
You would think that staying signed in, especially when the box is checked when I sign in, would fall under the heading of “strictly necessary”. Whoever set this cookielaw structure up is severely misguided, and they didn’t tell Zoom support enough about this crock so they could immediately know the answer to “I keep having to sign in over and over” complaints.
You can kill access and script-running to cookielaw .org once you’ve run this stupid gauntlet, and your browser will still keep this updated set of cookies intact and remember the sign-in state.