Google Calendar API v3 - 使用硬编码凭据进行身份验证
我正在编写一个 PHP 应用程序,它应该允许用户将某些事件添加到私人 Google 日历中.日历归我所有,我需要一种方式让 PHP 使用固定凭据与日历 API 通信(每个人都可以使用网站上的表单添加事件,但日历本身不公开可见).
I am writing a PHP application that's supposed to allow users to add certain events to a private Google Calendar. The calendar is owned by me, and I need a way for PHP to communicate with the calendar API using fixed credentials (everyone can add events using a form on the website, but the calendar itself is not publicly visible).
据我所知,使用 v1 API 中的 ClientLogin 是可能的.但是,在 v3 API 中,可用选项是 OAuth2.0 或 API 密钥.使用 API 密钥似乎不起作用,因为它只能用于不需要授权的请求,而且 OAuth 似乎也不对,因为用户不应该访问他们自己的日历,但是我的应用程序使用.
From what I have read, this is possible using ClientLogin in the v1 API. In the v3 API, however, the available options are OAuth2.0 or the API key. Using the API key doesn't seem to work, since it can only be used for requests that don't require authorization, and OAuth doesn't seem right either, because users are not supposed to access their own calendars, but the one my application uses.
我想以编程方式获取 OAuth 令牌,但这迟早会中断,因为 OAuth 对话框可以使用验证码.
I thought about getting the OAuth token programatically, but that's bound to break sooner or later, since the OAuth dialog can use captchas.
这似乎是一个标准用例——一个允许用户以一些预定义的方式与单个日历交互的 Web 应用程序——但我找不到任何关于如何在 v3 API 中实现它的文档.有人可以帮我吗?
This seems to be such a standard use case — a web application that lets users interact with a single calendar in some predefined ways — yet I can't find any documentation on how to make it happen in the v3 API. Can anyone help me?
推荐答案
您将需要同时使用开发人员密钥(API 密钥)和 OAuth2.开发人员密钥验证谁编写了软件,并用于诸如基于每个开发人员而不是每个用户的配额之类的事情.OAuth2用于用户认证,需要访问非公开日历.
You will need to use both the Developer Key (API Key) and OAuth2. The developer key authenticates who wrote the software and is used for things like quota which is on a per developer basis not a per user basis. OAuth2 is for user authentication and will be need to access the non-public calendar.
OAuth2 有一个更新令牌,您可以从中生成会话令牌,这意味着您无需通过屏幕抓取 OAuth 屏幕来获得身份验证.为了得到这个,我会写一个小的命令行应用程序,或者你使用一个单独的 PHP 页面.
OAuth2 has a renew token from which you can generate a session token and this means that you will not need to screen scrape the OAuth screens to get authenticated. To get this I would write a little command line application, or you use a one off PHP page.
- 在 Google Api Console 下,转到 API Access
- 生成一个新的客户端 ID 并选择已安装的应用程序(因为您将验证您的服务器而不是您的用户)
- 使用控制台应用程序或一次性 PHP 页面,使用 OAuth 和您的 Google 帐户(具有您要访问的日历的帐户)进行身份验证
- 在身份验证的返回中应该有一个更新令牌,(称为更新或刷新或类似的东西).保存此字符串并使其可用于您的 PHP 站点.
- 当您需要访问该服务时,您的 OAuth 库应该有一个更新/刷新调用.下面是一个使用 .Net 的示例.
- Under the Google Api Console go to API Access
- Generate a new Client ID and choose Installed Application ( as you will be authenticating you server as you not as your user)
- Either using a console app or a one off PHP page authenticate using OAuth and your google account (the one with the calendar you want access to)
- In the return from the authentication there should be a renew token, (called renew or refresh or something similar). Save this string and make it available to your PHP site.
- When you need to access the service your OAuth library should have a renew/refresh call. There is an example using .Net below.
<小时>
private IAuthorizationState CreateAuthorization(NativeApplicationClient arg)
{
// Get the auth URL:
IAuthorizationState state = new AuthorizationState(new[] { AdsenseService.Scopes.AdsenseReadonly.GetStringValue() });
state.Callback = new Uri(NativeApplicationClient.OutOfBandCallbackUrl);
if (refreshToken.IsNotNullOrEmpty()) // refreshToken you stored in step 4
{
try
{
state.RefreshToken = refreshToken;
if (arg.RefreshToken(state)) // This is calling out to the OAuth servers with the refresh token getting back a session token, returns true if successful.
{
if (state.RefreshToken != refreshToken) // if the refresh token has changed, save it.
{
PersistRefreshToken(authorization.RefreshToken);
}
return this.authorization = state; // Retain the authorization state, this is what will authenticate your calls.
}
}
catch (ProtocolException ex) {...}
现在已更新的 AuthorisationState 然后可用于验证您对 API 的调用.这个状态可以使用很多次,直到它过期,然后可以刷新.当您以您自己而不是用户身份验证您的应用程序时,此 AuthorisationState 可以由您的所有会话共享.当前的 AuthorisationState 和刷新令牌都应该安全地保存在您的服务器上,并且永远不会发送到客户端,如果您将它们作为响应的一部分发送,您的客户端将拥有与您的代码应用程序相同的权限
The AuthorisationState that has now been renewed can then be used to authenticate call you make to the API. this state can be used many time until it expires and then can be refreshed. As you are authenticating your application as yourself not as a user this AuthorisationState can be shared by all you sessions. Both the current AuthorisationState and the refresh token should be kept securely on your server and never sent to the client, if you ever sent these as part of a response your clients would have the same privileges as your code application
相关文章