Djangae Gauth 集成
Djangae Gauth integration
我正在关注 Djangae 文档的 "Gauth authentication" 部分，但我 运行 遇到了一些意外行为。
我已经按照文档的说明配置了 urls.py 和 settings.py（当前设置主要是使用 Djangae 脚手架的结果），但在任何时候都不会提示用户使用或进行身份验证link 他们的 Google 帐户。我试过 un/setting DJANGAE_CREATE_UNKNOWN_USER 但这没有任何影响。
我还在我的本地 shell 中尝试了受 sitepackages/prod/djangae/contrib/gauth/tests.py 启发的 运行 命令，以验证后端配置是否正确配置并且用户可以实际上针对 AppEngineUserAPIBackend 进行了身份验证，但失败了，因为我的用户模型 (djangae.contrib.gauth_datastore.models.GaeDatastoreUser) 似乎缺少必需的属性：AttributeError: 'GaeDatastoreUser' object has no attribute 'user_id'.
那么，我是否误解了这一切应该如何工作并且必须采取一些额外的步骤才能使 Google 登录正常工作？还是我（可能）错误配置了我的应用程序？ （我很高兴包含我的配置的通用版本，但正如我所说，它们直接来自 Djangae Scaffold 或文档。）
更新：有趣的是，如果我从我的行为套件配置中删除 --headless 标志，我会看到预期的行为。浏览器 (Chrome) 被重定向到 https://accounts.google.com/Login?continue=http%3A%2F%2Flocalhost%3A8080%2F
环境：
Djangae (0.9.11)
Django (1.11.19)
事实证明这是预期的行为。在本地沙箱中，系统会提示用户输入电子邮件地址，并且（默认情况下）为他们创建 "user" 并自动登录。
来自 App Engine 的 "Users Python API Overview" 文档：
Google accounts and the development server
The development server simulates the Google Accounts system using a
dummy sign-in screen. When your application calls the Users API to get
the URL for the sign-in screen, the API returns a special development
server URL that prompts for an email address, but no password. You can
type any email address into this prompt, and the app will behave as if
you are signed in with an account with that address.
The dummy sign-in screen also includes a checkbox that indicates
whether the dummy account is an administrator; that is, whether the
account has the the Viewer, Editor, or Owner primitive role, or the
App Engine App Admin predefined role. If you check this box, the app
will behave as if you are signed in using an administrator account.
Similarly, the Users API returns a sign-out URL that cancels the dummy
sign-in.
The unique ID for a User object in the development server is
calculated from the email address. Two unique email addresses always
represent two unique users in the development server.
个人认为这个设计是非常有缺陷的。我不知道 Google 对十二要素宣言的看法，但这种行为公然违反了第 10 条（Dev/Prod 奇偶校验），总结为 "Keep development, staging, and production as similar as possible"。我看不出为什么完整的 auth/redirect 流程在本地沙箱中不起作用，至少，用户应该能够选择加入它。 （我会 喜欢 发现这是一个选项。）
关于此条件行为最令人担忧的部分是用户对象的 API 不同，这就是为什么我看到问题中提到的错误（'GaeDatastoreUser' 对象没有属性 'user_id').本地用户也没有nickname方法。
我正在关注 Djangae 文档的 "Gauth authentication" 部分，但我 运行 遇到了一些意外行为。
我已经按照文档的说明配置了 urls.py 和 settings.py（当前设置主要是使用 Djangae 脚手架的结果），但在任何时候都不会提示用户使用或进行身份验证link 他们的 Google 帐户。我试过 un/setting DJANGAE_CREATE_UNKNOWN_USER 但这没有任何影响。
我还在我的本地 shell 中尝试了受 sitepackages/prod/djangae/contrib/gauth/tests.py 启发的 运行 命令，以验证后端配置是否正确配置并且用户可以实际上针对 AppEngineUserAPIBackend 进行了身份验证，但失败了，因为我的用户模型 (djangae.contrib.gauth_datastore.models.GaeDatastoreUser) 似乎缺少必需的属性：AttributeError: 'GaeDatastoreUser' object has no attribute 'user_id'.
那么，我是否误解了这一切应该如何工作并且必须采取一些额外的步骤才能使 Google 登录正常工作？还是我（可能）错误配置了我的应用程序？ （我很高兴包含我的配置的通用版本，但正如我所说，它们直接来自 Djangae Scaffold 或文档。）
更新：有趣的是，如果我从我的行为套件配置中删除 --headless 标志，我会看到预期的行为。浏览器 (Chrome) 被重定向到 https://accounts.google.com/Login?continue=http%3A%2F%2Flocalhost%3A8080%2F
环境：
Djangae (0.9.11)
Django (1.11.19)
事实证明这是预期的行为。在本地沙箱中，系统会提示用户输入电子邮件地址，并且（默认情况下）为他们创建 "user" 并自动登录。
来自 App Engine 的 "Users Python API Overview" 文档：
Google accounts and the development server
The development server simulates the Google Accounts system using a dummy sign-in screen. When your application calls the Users API to get the URL for the sign-in screen, the API returns a special development server URL that prompts for an email address, but no password. You can type any email address into this prompt, and the app will behave as if you are signed in with an account with that address.
The dummy sign-in screen also includes a checkbox that indicates whether the dummy account is an administrator; that is, whether the account has the the Viewer, Editor, or Owner primitive role, or the App Engine App Admin predefined role. If you check this box, the app will behave as if you are signed in using an administrator account.
Similarly, the Users API returns a sign-out URL that cancels the dummy sign-in.
The unique ID for a User object in the development server is calculated from the email address. Two unique email addresses always represent two unique users in the development server.
个人认为这个设计是非常有缺陷的。我不知道 Google 对十二要素宣言的看法，但这种行为公然违反了第 10 条（Dev/Prod 奇偶校验），总结为 "Keep development, staging, and production as similar as possible"。我看不出为什么完整的 auth/redirect 流程在本地沙箱中不起作用，至少，用户应该能够选择加入它。 （我会 喜欢 发现这是一个选项。）
关于此条件行为最令人担忧的部分是用户对象的 API 不同，这就是为什么我看到问题中提到的错误（'GaeDatastoreUser' 对象没有属性 'user_id').本地用户也没有nickname方法。