Keychain access required for proper initialization?

Desktop Client SDK macOS
#1

Description
Denying Keychain access prevents ZoomSDK from being authorized properly

Which version?
5.4.54528.1230

Additional context
I have noted the previous topics posted here about the new keychain access dialog asking for permission to use “(App Name) Safe Storage” and “(App Name) Safe Meeting Storage”. I see that these are present when launching the official Zoom client too, however in the official client starting/joining a meeting is still possible after choosing “Deny”, while when using the SDK this seems to prevent proper authorization and ZoomSDK.shared().getSettingService() (for example) returns nil if the user chooses Deny. So my questions are:

  1. Is this expected behavior if the user chooses Deny?
  2. If so, could the SDK be updated so that meetings are still possible after the user chooses Deny as is possible in the official client?
  3. Since the dialog doesn’t present a great experience for first time users of our app, could the SDK be updated to allow for opting out of requiring keychain access entirely?

Thanks for any help!

#2

Hi @brainbomb, thanks for the post.

I have not noticed any differences in functionality when denying those permissions with the sample application.

  1. Is this expected behavior if the user chooses Deny?

No, this is not expected behavior. Can you please try updating to the latest version of the SDK?

  1. If so, could the SDK be updated so that meetings are still possible after the user chooses Deny as is possible in the official client?

Meetings should still function normally regardless of your selection.

  1. Since the dialog doesn’t present a great experience for first time users of our app, could the SDK be updated to allow for opting out of requiring keychain access entirely?

This seems reasonable to me. I will submit a feature request to allow these requests to be hidden. There may be some aspects of the SDK (e.g. “remember me” option when logging in) that would not function without this, but as long as it is configurable to hide these, that should not pose any major issues. I will let you know as soon as we have any additional information on this feature request.

In the meantime, please don’t hesitate to reach out if you run into any other issues or have additional questions. :slightly_smiling_face:

Thanks!

#3

Hi Jon, appreciate your thoughtful response.
On further testing I see that Deny does still allow proper SDK authorization. It must have been a fluke before, sorry about that.

Being able to avoid the dialog entirely as you mentioned would still be ideal. Thanks for submitting this feature request!

#4

Hi @brainbomb,

Always happy to help! I will let you know as soon as we have any updates on the feature request.

I would also like to note that, in addition to the “remember me” login option, denying this permission may also impact persisting user settings across multiple sessions.

Thanks!

#5

Do you have updates for

  1. Since the dialog doesn’t present a great experience for first time users of our app, could the SDK be updated to allow for opting out of requiring keychain access entirely?