当前位置：文江博客话题详情

在Google同意屏幕上禁用复选框

发布于 2025-01-29 10:22:33 字数 494 浏览 4 评论 0 原文

我们正在使用Gmail .NET SDK实施Gmail发送ASP .NET Web应用程序。

为了做到这一点 https://www.googleapis.com/auth/auth/auth/gmail/gmail.send.send 但是，在同意书上，用户可以向我们授予我们，

可以解开“代表您发送电子邮件”的复选框，这对我们来说是不可接受的，请参见下面：

我们已经看到了很多示例在Google同意屏幕上没有启用的复选框

。我不确定这是否是原因。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

月依秋水 2025-02-05 10:22:33

答案：

这些复选框是由于新的颗粒帐户许可系统的滚动，它们是完全正常的，无法关闭的。

准备更改以来，答案已经过去26个月：

以下是Google提供的指南，以准备如何为Oauth和APIS的Google帐户许可系统做准备：

查看
API调用，查看用户是否已授予您的应用程序，这将帮助您避免使用足够的许可错误，这可能会导致意外的应用程序错误和不良的用户体验。：
- android
- ios
仅在需要时请求权限。您将能够在要求每次许可的情况下上台，我们建议您在上下文中进行考虑。您应该避免在登录时要求多个示波器，当用户可能第一次使用您的应用程序并且不熟悉该应用程序的功能时。将多个范围的请求捆绑在一起，使用户很难理解为什么您的应用需要许可，并可能会警告并阻止他们进一步使用您的应用程序。
在要求访问之前提供理由。清楚地说明了为什么需要访问，用户的数据如何处理以及如何从提供访问中受益。我们的研究表明，这些解释增加了用户的信任和参与度。

您可以阅读上述博客文章以获取有关更改的完整信息。

参考：

Answer:

These checkboxes are due to the rolling out of a new granular account permission system, they are completely normal, and can not be turned off.

More Information:

After some digging, I discovered this Google Developers blog post from 2018 in which it is discussed that in the new permission system, users will have the ability to grant or deny permissions individually.

From the blog post:

Over the next few months, we'll start rolling out an improvement to our API infrastructure. We will show each permission that an app requests one at a time, within its own dialog, instead of presenting all permissions in a single dialog*. Users will have the ability to grant or deny permissions individually.

*our different login scopes (profile, email, and openid are all combined in the same consent and don't need to be requested separately.

It seems that this is still in the roll-out phase, even though at the time of writing this answer 26 months have passed since the announcement.

Preparing for the change:

The following are guidelines provided by Google as to how to prepare for the changes they are making to the Google Account permission system for OAuth and APIs:

Review the Google API Services: User Data Policy and make sure you are following them.
Before making an API call, check to see if the user has already granted permission to your app. This will help you avoid insufficient permission errors which could lead to unexpected app errors and a bad user experience. Learn more about this by referring to documentation on your platform below:
- Documentation for Android
- Documentation for the web
- Documentation for iOS
Request permissions only when you need them. You'll be able to stage when each permission is requested, and we recommend being thoughtful about doing this in context. You should avoid asking for multiple scopes at sign-in, when users may be using your app for the first time and are unfamiliar with the app's features. Bundling together a request for several scopes makes it hard for users to understand why your app needs the permission and may alarm and deter them from further use of your app.
Provide justification before asking for access. Clearly explain why you need access, what you'll do with a user's data, and how they will benefit from providing access. Our research indicates that these explanations increase user trust and engagement.

You can read the aforelinked blog post for full information about the change.

References:

回复收藏 0 原文

~没有更多了~

关于作者

剪不断理还乱

暂无简介

文章

28 人气

关注发私信

友情链接

文江博客

在Google同意屏幕上禁用复选框

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

评论（1）

答案：