約 949,184 件
https://w.atwiki.jp/api_programming/pages/37.html
下位ページ Content 認証リクエスト OAuth2.0 の概要 WebサーバアプリケーションのOauth 2.0認証 Using OAuth 2.0 for Web Server Applications 概要 認証プロトコルについて OAuth 2.0 による認証 いろんな言語のライブラリ web application credentialsを作る web application credentials を得るステップ Preparing to start the OAuth 2.0 flowGoogle's OAuth 2.0 サーバにリダイレクト OAuth 2.0 serverのレスポンスを扱う Google APIsを呼び出す サンプル完全版Incremental authorization Offline accessトークンのリクエストjava? リダイレクトのURLから、codeを処理する authorization code と access token の交換 認証リクエスト Google APIにリクエストを送るには、アプリケーションの「identify」が必要で、その方法は2つある。 OAuth 2.0 token (which also authorizes the request) API key どちらをつかうのか、は以下で決まる。 プライベートデータを使うときは、OAuth 2.0 token でなければならない。アプリケーションには API key も配布されるが必須でない。 パブリックデータを使うときは the API key でも OAuth 2.0 token 使いやすい方で良い, or both—whatever option is most convenient for you. OAuth2.0 の概要 https //developers.google.com/identity/protocols/OAuth2?csw=1 WebサーバアプリケーションのOauth 2.0認証 Using OAuth 2.0 for Web Server Applications Google API の認証 Google Identity Platform https //developers.google.com/identity/protocols/OAuth2WebServer Using OAuth 2.0 for Web Server Applications Google APIsを使うために、Google API Client Libraries or Google OAuth 2.0 endpoints が使える。 OAuth 2.0 で、ユーザは、ユーザ名やパスワードをプログラムに渡すことなく、Google アプリケーションのデータが使える。 概要 まず、APIコンソールでプロジェクトの「web application credentials」をつくる。アプリケーションがユーザーデータにアクセスする必要がある場合は、ユーザーはGoogle's OAuth 2.0 serverにリダイレクトされる。OAuth 2.0 server はユーザ承認をして、アプリケーションからのデータアクセスに必要な「consent」を得る。 OAuth 2.0 serverはユーザーをアプリケーションにリダイレクトする（戻す）。このとき、承認コードを返す。アプリケーションで承認コードをアクセストークンに交換する。 アプリケーションは承認コードを使って、Google API にアクセスする。 When you use a Google API Client Library to handle your application's OAuth 2.0 flow, the client library keeps track of when a stored access token can be used and when the application must re-acquire consent, generates correct redirect URLs, and helps to implement redirect handlers that exchange authorization codes for access tokens. An application that carries out the OAuth 2.0 flow without using a client library must correctly complete the same steps. Client libraries The language-specific examples on this page make use of the Google API Client Libraries, which make API authorization with OAuth 2.0 simpler. To run the example code, you must first install the client library for your language. 認証プロトコルについて OAuth 2.0しかないが、Google Sign-In が使えるアプリケーションなら、違う「扱い方」をすることが可能 OAuth 2.0 による認証 Requests to the Google Sheets API for non-public user data must be authorized by an authenticated user. The details of the authorization process, or "flow," for OAuth 2.0 vary somewhat depending on what kind of application you're writing. The following general process applies to all application types アプリケーションを作成したら、Google API Console に使用登録をする。これに関する細かな情報は後述。 （Sheets API を使うのであれば）Google Sheets API を Google API Console でアクティベートする。（使用する API がリストになければ、このステップは飛ばす） アプリケーションがユーザーデータを必要とするのであれば、Google に アクセススコープを要求する。 Google はユーザーに確認画面を表示し、アプリケーションを認証するか尋ねる。 ユーザが認証したら、Google がアプリケーションにアクセストークンを発行する。 アプリケーションがユーザーデータ（プライベートデータ）を要求する場合は、アクセストークンをつけて要求する。 Google はリクエストとトークンが有効と判断したら、要求されたデータを返す 以上が基本の流れで、ところどころ追加ステップが必要になる。例えば、トークンの有効期限が切れた場合のリフレッシュ作業など。 いろんな言語のライブラリ 省略 web application credentialsを作る All web applications that use OAuth 2.0 must have credentials that identify the application to the OAuth 2.0 server. Applications that have these credentials can access the APIs that you enabled for your project. web application credentials を得るステップ APIコンソールの認証情報ページへ。 （まだ作っていなければ）「認証情報を作成」をクリックして、OAuth クライアント ID を選択する。 次に、クライアントIDとクライアントSecretを探す。 リダイレクトURIも編集。リダイレクトURIはエンドポイントで、レスポンスに乗ってくる情報を処理する。ローカルマシンで試す場合は、http //localhost 8080みたいなのも可。 client_secrets.jsonファイルをダウンロードしてセキュリティ性を保って保管する（ほうがいい） Important Do not store the client_secrets.json file in a publicly-accessible location, and if you share the source code to your application—for example, on GitHub—store the client_secrets.json file outside of your source tree to avoid inadvertently sharing your client credentials. Preparing to start the OAuth 2.0 flow If you are using a Google API client library to handle the OAuth 2.0 flow, configure the client object, which you will use to make OAuth 2.0 requests. If you are handling the flow by directly accessing the OAuth 2.0 endpoints, just take note of the client ID that you created in the previous step and the scopes you need to request. To configure the client object HTTP/REST Take note of the following values Your app's client ID and client secret, which you created in Creating web application credentials. The scopes that your app needs to request. See the documentation for the APIs your app uses for the required scopes. Google's OAuth 2.0 サーバにリダイレクト HTTP/REST https //accounts.google.com/o/oauth2/v2/auth HTTP はだめ。HTTPSで。 https //accounts.google.com/o/oauth2/v2/auth? scope=email%20profile state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Foauth2.example.com%2Fcode , response_type=code client_id=812741506391.apps.googleusercontent.com The set of query string parameters supported by the Google Authorization Server for web server applications are Parameter Values Description response_type code Determines whether the Google OAuth 2.0 endpoint returns an authorization code. Web server applications should use code. client_id クライアントID リクエストを出したクライアントの特定 required redirect_uri コンソールで登録したリダイレクトURIの一つ 登録されたURIとピッタリ合わないとだめ。(http / https も scope アプリケーションにリクエストするパーミッション（スペース区切り） 使うスコープは承認画面でユーザーに公開される。要求されたパーミッション数と、ユーザーの同意を得る可能性との間には逆の可能性があります。使えるスコープの種類は、APIs Explorerで確認のこと。It is generally a best practice to request scopes incrementally, at the time access is required, rather than up front. 例えば、For example, an app that wants to support purchases should not request Google Wallet access until the user presses the “buy” button; see Incremental authorization. state Any string Provides any state that might be useful to your application upon receipt of the response. The Google Authorization Server roundtrips this parameter, so your application receives the same value it sent. To mitigate against cross-site request forgery (CSRF), it is strongly recommended to include an anti-forgery token in the state, and confirm it in the response. See OpenID Connect for an example of how to do this. access_type online / offline Indicates whether your application needs to access a Google API when the user is not present at the browser. This parameter defaults to online. If your application needs to refresh access tokens when the user is not present at the browser, then use offline. This will result in your application obtaining a refresh token the first time your application exchanges an authorization code for a user. prompt Space-delimited, case-sensitive list of prompts to present the user. If you don't specify this parameter, the user will be prompted only the first time your app requests access. 可能なあたいとして、"none" 画面を出さないMust not be specified with other values. consentPrompt the user for consent select_accountPrompt the user to select an account login_hint email address or sub identifier When your application knows which user it is trying to authenticate, it can provide this parameter as a hint to the Authentication Server. Passing this hint will either pre-fill the email box on the sign-in form or select the proper multi-login session, thereby simplifying the login flow. include_granted_scopes true / false If this is provided with the value true, and the authorization request is granted, the authorization will include any previous authorizations granted to this user/application combination for other scopes; see Incremental Authorization. After you create the request URL, redirect the user to it. Google's OAuth 2.0 server will authenticate the user and obtain consent from the user for your application to access the requested scopes. The response will be sent back to your application using the redirect URL you specified. OAuth 2.0 serverのレスポンスを扱う ユーザがアクセス要求を承認すると、認証コードが送られてくる。 承認しなければ、レスポンスにはエラーメッセージが含まれてくる。 All responses are returned to the web server on the query string, as shown below エラー https //oauth2.example.com/auth?error=access_denied 承認 https //oauth2.example.com/auth?code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 Important If your response endpoint renders an HTML page, any resources on that page will be able to see the authorization code in the URL. Scripts can read the URL directly, and all resources may be sent the URL in the Referer HTTP header. Carefully consider if you want to send authorization credentials to all resources on that page (especially third-party scripts such as social plugins and analytics). To avoid this issue, we recommend that the server first handle the request, then redirect to another URL that doesn't include the response parameters. 認証コードを受け取ったら、アクセストークンと交換 ここにアクセス https //www.googleapis.com/oauth2/v4/token 使用するパラメータ Field Description code The authorization code returned from the initial request. client_id The client ID obtained from the API Console. client_secret The client secret obtained from the API Console. redirect_uri One of the redirect URIs listed for this project in the API Console. grant_type As defined in the OAuth 2.0 specification, this field must contain a value of authorization_code. リクエスト例 POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 client_id=8819981768.apps.googleusercontent.com client_secret={client_secret} redirect_uri=https //oauth2.example.com/code grant_type=authorization_code リクエストが通ると以下のレスポンスが戻る Field Description access_token Google APIにアクセスするためのトークン refresh_token 新しいアクセストークンを得るためのトークン。ユーザが承認を取り消すまで有効。このフィールドは access_type=offline が認証コードリクエストに含まれていれば、only present expires_in The remaining lifetime of the access token. token_type Identifies the type of token returned. At this time, this field will always have the value Bearer. レスポンスはJSONで帰ってくる { "access_token" "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in" 3920, "token_type" "Bearer" } Note Other fields may be included in the response, and your application should not treat this as an error. The set shown above is the minimum set. Google APIsを呼び出す HTTP/REST access tokenを使って、APIを呼び出す。access token は （サーバログに残ってしまうので良くないが）"access_token" としてパラメータに含めるか、 （推奨は）HTTPヘッダの Authorization Bearer に含める。 You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground. 例 A call to the drive.files endpoint (the Drive API) using the access_token query string parameter might look like the following, though you'll need to specify your own access token GET https //www.googleapis.com/drive/v2/files?access_token=1/fFBGRNJru1FQd44AzqT3Zg Authorization Bearer HTTP header を使って同じことをすると GET /drive/v2/files HTTP/1.1 Authorization Bearer 1/fFBGRNJru1FQd44AzqT3Zg Host googleapis.com You can try out with the curl command-line application. Here's an example using the HTTP header option (preferred) curl -H "Authorization Bearer 1/fFBGRNJru1FQd44AzqT3Zg" https //www.googleapis.com/drive/v2/files Or, alternatively, the query string parameter option curl https //www.googleapis.com/drive/v2/files?access_token=1/fFBGRNJru1FQd44AzqT3Zg Google/Sheets API サンプル完全版 The following example prints a JSON-formatted list of files in a user's Google Drive after the user authenticates and gives consent for the application to access the user's Drive files. HTTP/REST This example in Python uses the Flask framework and the Requests library to demonstrate the OAuth 2.0 web flow. Note that using the Python client library is easier and is the recommended way to implement this flow. import json import flask import requests app = flask.Flask(__name__) CLIENT_ID = '123456789.apps.googleusercontent.com' CLIENT_SECRET = 'abc123' # Read from a file or environmental variable in a real app SCOPE = 'https //www.googleapis.com/auth/drive.metadata.readonly' REDIRECT_URI = 'http //example.com/oauth2callback' @app.route('/') def index() if 'credentials' not in flask.session return flask.redirect(flask.url_for('oauth2callback')) credentials = json.loads(flask.session['credentials']) if credentials['expires_in'] = 0 return flask.redirect(flask.url_for('oauth2callback')) else headers = {'Authorization' 'Bearer {}'.format(credentials['access_token'])} req_uri = 'https //www.googleapis.com/drive/v2/files' r = requests.get(req_uri, headers=headers) return r.text @app.route('/oauth2callback') def oauth2callback() if 'code' not in flask.request.args auth_uri = ('https //accounts.google.com/o/oauth2/v2/auth?response_type=code' ' client_id={} redirect_uri={} scope={}').format(CLIENT_ID, REDIRECT_URI, SCOPE) return flask.redirect(auth_uri) else auth_code = flask.request.args.get('code') data = {'code' auth_code, 'client_id' CLIENT_ID, 'client_secret' CLIENT_SECRET, 'redirect_uri' REDIRECT_URI, 'grant_type' 'authorization_code'} r = requests.post('https //www.googleapis.com/oauth2/v4/token', data=data) flask.session['credentials'] = r.text return flask.redirect(flask.url_for('index')) if __name__ == '__main__' import uuid app.secret_key = str(uuid.uuid4()) app.debug = False app.run() Incremental authorization In the OAuth 2.0 protocol, your app requests authorization to access resources which are identified by scopes, and assuming the user is authenticated and approves, your app receives short-lived access tokens which let it access those resources, and (optionally) refresh tokens to allow long-term access. It is considered a best user-experience practice to request authorization for resources at the time you need them. For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it. In this case, at sign-in time the app might request the profile scope to perform basic sign-in, and then later request the https //www.googleapis.com/auth/drive.file scope at the time of the first request to save a mix. Using the procedures described in Using OpenID Connect and Using OAuth 2.0 to Access Google APIs would normally result in your app having to manage two different access tokens. To avoid this complexity, you can include previously granted scopes in your authorization requests. For example HTTP/REST GET https //accounts.google.com/o/oauth2/v2/auth? scope=https //www.googleapis.com/auth/drive.file state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Fmyapp.example.com%2Fcallback response_type=code client_id=8127352506391.apps.googleusercontent.com prompt=consent include_granted_scopes=true Let's call the resulting authorization the "combined authorization"; the following apply You can use the access tokens you get to access the resources corresponding to any of the scopes that are rolled into the combined authorization. When you use the refresh token for a combined authorization, the new access tokens represent the combined authorization and can be used for any of its scopes. The combined authorization includes any previously granted authorizations even if they were requested from different clients. For example, if you requested the profile scope from a desktop app, and then issued the request in the example URI above for the same user from a mobile app, and it was granted, the combined authorization would include both scopes. When you revoke a token which represents a combined authorization, all of the authorizations are revoked simultaneously; this means that if you retain a token for one of the previous authorizations, it will stop working. When you make an authorization request with granted scopes included, the Google authorization server rolls the authorization request together with all the previous authorizations granted to the requesting user from the requesting app. Offline access ユーザが使っていない場合でもAPIにアクセスする必要がある場合があるかも。たとえば、バックアップの場合や「月曜８時にBlobをポスト」のような場合。 このタイプのアクセスを「offline」と呼び、ウェブサーバアプリはオフラインリクエストができる。 これに対し、通常のアクセスはonlineである。 HTTP/REST If your application needs offline access to a Google API, then the request for an authorization code should include the access_type parameter, where the value of that parameter is offline. For example https //accounts.google.com/o/oauth2/v2/auth? scope=email%20profile state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Foauth2.example.com%2Fcode response_type=code client_id=812741506391.apps.googleusercontent.com access_type=offline The first time a given user's browser is sent to this URL, they see a consent page. If they grant access, then the response includes an authorization code which may be redeemed for an access token and a refresh token. An example of an authorization code exchange is shown below POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 client_id=8819981768.apps.googleusercontent.com client_secret={client_secret} redirect_uri=https //oauth2.example.com/code grant_type=authorization_code If this is the first time the application has exchanged an authorization code for a user, then the response includes an access token and a refresh token, as shown below { "access_token" "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in" 3920, "token_type" "Bearer", "refresh_token" "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" } Important When your application receives a refresh token, it is important to store that refresh token for future use. If your application loses the refresh token, it will have to re-prompt the user for consent before obtaining another refresh token. If you need to re-prompt the user for consent, include the prompt parameter in the authorization code request, and set the value to consent. After your application receives the refresh token, it can obtain new access tokens at any time. See the section on refresh tokens for more information. The next time your application requests an authorization code for that user, the user will not be asked to grant consent (assuming they previously granted access, and you are asking for the same scopes). As expected, the response includes an authorization code which may be redeemed. However, unlike the first time an authorization code is exchanged for a given user, a refresh token will not be returned from the authorization code exchange. The following is an example of such a response { "access_token" "1/fFAGRNJru1FQd77BzhT3Zg", "expires_in" 3920, "token_type" "Bearer", } Using a refresh token As indicated in the previous section, a refresh token is obtained in offline scenarios during the first authorization code exchange. In these cases, your application may obtain a new access token by sending a refresh token to the Google OAuth 2.0 Authorization server. To obtain a new access token this way, your application sends an HTTPS POST request to https //www.googleapis.com/oauth2/v4/token. The request must include the following parameters FieldDescription refresh_tokenThe refresh token returned from the authorization code exchange. client_idThe client ID obtained from the API Console. client_secretThe client secret obtained from the API Console. grant_typeAs defined in the OAuth 2.0 specification, this field must contain a value of refresh_token. Such a request will look similar to the following POST /oauth2/v4/token HTTP/1.1 Host www.googleapis.com Content-Type application/x-www-form-urlencoded client_id=8819981768.apps.googleusercontent.com client_secret={client_secret} refresh_token=1/6BMfW9j53gdGImsiyUH5kU5RsR4zwI9lUVX-tqf8JXQ grant_type=refresh_token As long as the user has not revoked the access granted to your application, the response includes a new access token. A response from such a request is shown below { "access_token" "1/fFBGRNJru1FQd44AzqT3Zg", "expires_in" 3920, "token_type" "Bearer", } Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working. Revoking a token In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed. PHPPYTHONRUBYHTTP/REST To programmatically revoke a token, your application makes a request to https //accounts.google.com/o/oauth2/revoke and includes the token as a parameter curl https //accounts.google.com/o/oauth2/revoke?token={token} The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked. If the revocation is successfully processed, then the status code of the response is 200. For error conditions, a status code 400 is returned along with an error code. Note Following a successful revocation response, it might take some time before the revocation has full effect. Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates. Using OAuth 2.0 with the Google API Client Library for Java {{ Authorization Code Flow https //code.google.com/p/google-api-java-client/wiki/OAuth2#Authorization_Code_Flow 実装にはGoogleAuthorizationCodeFlowを用いる。 まず、API使用が登録済みであること。client id, client secret等々をもらっておく Authorization codeをもらう持っていなければ、認証URLへ。 ユーザIDをもとに、AuthorizationCodeFlow.loadCredential(String userID)を呼び出す既に証明書を持っているかを確認。持っていれば、終了。 認証されると、"code"と一緒にリダイレクトされる。 "code"を使って access token を要求する AuthorizationCodeFlow.newTokenRequest(String)でアクセストークン(access token)を要求。AuthorizationCodeFlow.createAndStoreCredential(TokenResponse, String) http //javadoc.google-oauth-java-client.googlecode.com/hg/1.18.0-rc/com/google/api/client/auth/oauth2/AuthorizationCodeFlow.html#createAndStoreCredential(com.google.api.client.auth.oauth2.TokenResponse,%20java.lang.String)]] で、証明書を取得し保管。 レスポンスからaccess tokenを取得 ※Lower-Levelの実装方法もある https //code.google.com/p/google-api-java-client/wiki/OAuth2#Authorization_Code_Flow }} トークンのリクエスト リクエスト先 https //accounts.google.com/o/oauth2/authSSLを使用すること。httpはダメ リクエストに加えるのは Parameter Values 必須 Description response_type "code" ◯ Webサーバアプリケーションでは code で決め打ち client_id client_id ◯ API使用の登録で貰ったID．忘れていたらconsoleで確認 redirect_uri One of the redirect_uri ◯？ リダイレクト先は複数登録されているので、どこにリダイレクトするのかここで書いておく。 scope Space-delimited set of permissions that the application requests. ◯ APIでどこまでユーザーのデータにアクセスするか（できるか）。複数ある場合はスペース区切り。どのような値を入れるかは、各APIのリファレンスページ（the APIs Explorer）参照。極力「最小」にしておく。必要なら後で追加認証をする感じで。 state Any string レスポンスを受け取る際に使える「状態」。cross-site request forgery (CSRF)の対策？なので、強く推奨。レスポンスを受け取って、これを確認すれば、変なとこで使われていないか、確認できる。 access_type offline or online ユーザがブラウザを使ってない時でもアプリケーションがアクセスするかどうか。自動的にトークンのリフレッシュが必要ならoffline。 approval_prompt force or auto optional デフォルトでauto 接続の度にプロンプトを出して訊くかどうか？ login_hint email address or sub identifier optional どのユーザが認証を行おうとしているかアプリケーション側でわかっている場合、（例えばそのユーザのemailアドレスを）パラメータとして渡すことができる。 include_granted_scopes true or false optional If this is provided with the value true, and the authorization request is granted, the authorization will include any previous authorizations granted to this user/application combination for other scopes; see Incremental Authorization. リクエストのスペース等々はエスケープする。 java.net.URLEncoder とか サンプル（改行は見やすくするため） https //accounts.google.com/o/oauth2/auth? scope=email%20profile state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome redirect_uri=https%3A%2F%2Foauth2-login-demo.appspot.com%2Fcode , response_type=code client_id=812741506391.apps.googleusercontent.com approval_prompt=force リクエストが正しく通れば、以下が返ってくる access tokens refresh tokens authorization codes. java? AuthorizationCodeFlow.newAuthorizationUrl()が使える？ リダイレクトのURLから、codeを処理する Handling the response The response will be sent to the redirect_uri as specified in the request URL. If the user approves the access request, then the response contains an authorization code and the state parameter (if included in the request). If the user does not approve the request, the response contains an error message. All responses are returned to the web server on the query string, as shown below 認証失敗 https //oauth2-login-demo.appspot.com/code? bold(){error=access_denied} state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome 認証成功 https //oauth2-login-demo.appspot.com/code?state=security_token%3D138r5719ru3e1%26url%3Dhttps //oa2cb.example.com/myHome bold(){code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7} リダイレクト先が通常のHTMLページの場合は、そのままURLが見える、つまりcodeが見えてしまう。 Scripts can read the URL directly, and all resources may be sent the URL in the Referer HTTP header. Carefully consider if you want to send authorization credentials to all resources on that page (especially third-party scripts such as social plugins and analytics). この問題を避けるために、サーバでリクエストを扱って、それからパラメータを含まない形で別のURLにリダイレクトするべき。 authorization code と access token の交換 After the web server receives the authorization code, it may exchange the authorization code for an access token and a refresh token. This request is an HTTPS POST to the URL https //www.googleapis.com/oauth2/v3/token, and includes the following parameters Field Description code authorization code client_id The client ID client_secret The client secret obtained from the Developers Console redirect_uri One of the redirect URIs grant_type ここでは "authorization_code" の決め打ち レスポンス例（成功時） { "access_token" "ya29.vAHSwBFxEzkYKAeqk461biUJ9dqSD8KglnarHgBaR7q7Ih_4TlT71KEh07QBR6_tfLVv", "token_type" "Bearer", "expires_in" 3600}
https://w.atwiki.jp/api_programming/pages/256.html
https //ja.wikipedia.org/wiki/Flask https //palletsprojects.com/p/flask/ https //flask.palletsprojects.com/en/1.1.x/api/ Cookie 書き込み Responceオブジェクトをつくるmake_response responceオブジェクトでset_cookieでセット responce をブラウザに送る https //flask.palletsprojects.com/en/1.1.x/api/#response-objects set_cookie 読み出し
https://w.atwiki.jp/api_programming/pages/194.html
下位ページ Content PrerequisitesCreate authorization credentials Identify access scopes Obtaining OAuth 2.0 access tokensStep 1 Configure the client object Step 2 Redirect to Google's OAuth 2.0 serverサンプル（Sample redirect to Google's authorization server） OAuth 2.0 for Client-side Web Applications OAuth 2.0 for Client-side Web Applications This document explains how to implement OAuth 2.0 authorization to access Google APIs from a JavaScript web application. OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, an application can use OAuth 2.0 to obtain permission from users to store files in their Google Drives. This OAuth 2.0 flow is called the implicit grant flow. It is designed for applications that access APIs only while the user is present at the application. These applications are not able to store confidential information. In this flow, your app opens a Google URL that uses query parameters to identify your app and the type of API access that the app requires. You can open the URL in the current browser window or a popup. The user can authenticate with Google and grant the requested permissions. Google then redirects the user back to your app. The redirect includes an access token, which your app verifies and then uses to make API requests. Note Given the security implications of getting the implementation correct, we strongly encourage you to use OAuth 2.0 libraries when interacting with Google's OAuth 2.0 endpoints. It is a best practice to use well-debugged code provided by others, and it will help you protect yourself and your users. See the JS Client Library tabs in this document for examples that show how to authorize users with the Google APIs Client Library for JavaScript. Prerequisites Enable APIs for your project Any application that calls Google APIs needs to enable those APIs in the API Console. To enable the appropriate APIs for your project Open the Library page in the API Console. Select the project associated with your application. Create a project if you do not have one already. Use the Library page to find each API that your application will use. Click on each API and enable it for your project. Create authorization credentials Any application that uses OAuth 2.0 to access Google APIs must have authorization credentials that identify the application to Google's OAuth 2.0 server. The following steps explain how to create credentials for your project. Your applications can then use the credentials to access APIs that you have enabled for that project. Open the Credentials page in the API Console. Click Create credentials OAuth client ID. Complete the form. Set the application type to Web application. Applications that use JavaScript to make authorized Google API requests must specify authorized JavaScript origins. The origins identify the domains from which your application can send API requests. Identify access scopes Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there may be an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent. Before you start implementing OAuth 2.0 authorization, we recommend that you identify the scopes that your app will need permission to access. The OAuth 2.0 API Scopes document contains a full list of scopes that you might use to access Google APIs. Obtaining OAuth 2.0 access tokens The following steps show how your application interacts with Google's OAuth 2.0 server to obtain a user's consent to perform an API request on the user's behalf. Your application must have that consent before it can execute a Google API request that requires user authorization. Step 1 Configure the client object If you are using Google APIs client library for JavaScript to handle the OAuth 2.0 flow, your first step is to configure the gapi.auth2 and gapi.client objects. These objects enable your application to obtain user authorization and to make authorized API requests. The client object identifies the scopes that your application is requesting permission to access. These values inform the consent screen that Google displays to the user. The Choosing access scopes section provides information about how to determine which scopes your application should request permission to access. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS If you are directly accessing the OAuth 2.0 endpoints, you can proceed to the next step. Step 2 Redirect to Google's OAuth 2.0 server To request permission to access a user's data, redirect the user to Google's OAuth 2.0 server. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS Generate a URL to request access from Google's OAuth 2.0 endpoint at https //accounts.google.com/o/oauth2/v2/auth. This endpoint is accessible over HTTPS; plain HTTP connections are refused. The Google authorization server supports the following query string parameters for web server applications Parameters client_id 必須The client ID for your application. You can find this value in the API Console. redirect_uri 必須ユーザが認証を行った後、API サーバがリダイレクトする場所を指定。この値は API Console で指定したリダイレクトURLのどれかと正確に一致している必要がある。http or https, case, ('/') まですべて一致。 response_type 必須JavaScript アプリケーションでは token を指定する。この指示により Google 認証サーバは アクセストークンを name=value のペアで、ハッシュ (#) fragment をつけて、返すようになる。 scope 必須A space-delimited list of scopes that identify the resources that your application could access on the user's behalf. These values inform the consent screen that Google displays to the user. Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there is an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent. The OAuth 2.0 API Scopes document provides a full list of scopes that you might use to access Google APIs. We recommend that your application request access to authorization scopes in context whenever possible. By requesting access to user data in context, via incremental authorization, you help users to more easily understand why your application needs the access it is requesting. state RecommendedSpecifies any string value that your application uses to maintain state between your authorization request and the authorization server's response. The server returns the exact value that you send as a name=value pair in the hash (#) fragment of the redirect_uri after the user consents to or denies your application's access request. You can use this parameter for several purposes, such as directing the user to the correct resource in your application, sending nonces, and mitigating cross-site request forgery. Since your redirect_uri can be guessed, using a state value can increase your assurance that an incoming connection is the result of an authentication request. If you generate a random string or encode the hash of a cookie or another value that captures the client's state, you can validate the response to additionally ensure that the request and response originated in the same browser, providing protection against attacks such as cross-site request forgery. See the OpenID Connect documentation for an example of how to create and confirm a state token. include_granted_scopes OptionalEnables applications to use incremental authorization to request access to additional scopes in context. If you set this parameter's value to true and the authorization request is granted, then the new access token will also cover any scopes to which the user previously granted the application access. See the incremental authorization section for examples. login_hint OptionalIf your application knows which user is trying to authenticate, it can use this parameter to provide a hint to the Google Authentication Server. The server uses the hint to simplify the login flow either by prefilling the email field in the sign-in form or by selecting the appropriate multi-login session. Set the parameter value to an email address or sub identifier. promptOptional. A space-delimited, case-sensitive list of prompts to present the user. If you don't specify this parameter, the user will be prompted only the first time your app requests access. Possible values are noneDo not display any authentication or consent screens. Must not be specified with other values. consentPrompt the user for consent. select_accountPrompt the user to select an account. サンプル（Sample redirect to Google's authorization server） An example URL is shown below, with line breaks and spaces for readability. https //accounts.google.com/o/oauth2/v2/auth ?scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly include_granted_scopes=true state=state_parameter_passthrough_value redirect_uri=http%3A%2F%2Foauth2.example.com%2Fcallback response_type=token client_id=client_id After you create the request URL, redirect the user to it. JavaScript sample code The following JavaScript snippet shows how to initiate the authorization flow in JavaScript without using the Google APIs Client Library for JavaScript. Since this OAuth 2.0 endpoint does not support Cross-origin resource sharing (CORS), the snippet creates a form that opens the request to that endpoint. /* * Create form to request access token from Google's OAuth 2.0 server. */ function oauthSignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https //accounts.google.com/o/oauth2/v2/auth'; // Create form element to submit parameters to OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id' 'YOUR_CLIENT_ID', 'redirect_uri' 'YOUR_REDIRECT_URI', 'response_type' 'token', 'scope' 'https //www.googleapis.com/auth/drive.metadata.readonly', 'include_granted_scopes' 'true', 'state' 'pass-through value'}); // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); } Step 3 Google prompts user for consent In this step, the user decides whether to grant your application the requested access. At this stage, Google displays a consent window that shows the name of your application and the Google API services that it is requesting permission to access with the user's authorization credentials. The user can then consent or refuse to grant access to your application. Your application doesn't need to do anything at this stage as it waits for the response from Google's OAuth 2.0 server indicating whether the access was granted. That response is explained in the following step. Step 4 Handle the OAuth 2.0 server response JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS The OAuth 2.0 server sends a response to the redirect_uri specified in your access token request. If the user approves the request, then the response contains an access token. If the user does not approve the request, the response contains an error message. The access token or error message is returned on the hash fragment of the redirect URI, as shown below An authorization code response https //oauth2.example.com/callback#access_token=4/P7q7W91 token_type=Bearer expires_in=3600 In addition to the access_token parameter, the query string also contains the token_type parameter, which is always set to Bearer, and the expires_in parameter, which specifies the lifetime of the token, in seconds. If the state parameter was specified in the access token request, its value is also included in the response. An error response https //oauth2.example.com/callback#error=access_denied Note Your application should ignore any additional, unrecognized fields included in the query string. Sample OAuth 2.0 server response You can test this flow by clicking on the following sample URL, which requests read-only access to view metadata for files in your Google Drive https //accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly include_granted_scopes=true state=state_parameter_passthrough_value redirect_uri=http%3A%2F%2Foauth2.example.com%2Fcallback response_type=token client_id=client_id After completing the OAuth 2.0 flow, you will be redirected to http //localhost/oauth2callback. That URL will yield a 404 NOT FOUND error unless your local machine happens to serve a file at that address. The next step provides more detail about the information returned in the URI when the user is redirected back to your application. The code snippet in step 5 shows how to parse the OAuth 2.0 server response and then validate the access token. Step 5 Validate the user's token JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS If the user has granted access to your application, you must explicitly validate the token returned in the hash fragment of the redirect_uri. By validating, or verifying, the token, you ensure that your application is not vulnerable to the confused deputy problem. To validate the token, send a request to https //www.googleapis.com/oauth2/v3/tokeninfo and set the token as the access_token parameter's value. The following URL shows a sample request https //www.googleapis.com/oauth2/v3/tokeninfo?access_token= access_token Google's authorization server responds to the request with a JSON object that either describes the token or contains an error message. If the token is valid, the JSON object includes the properties in the following table Fields audThe application that is the intended user of the access token. Important Before using the token, you need to verify that this field's value exactly matches your Client ID in the Google API Console. This verification ensures that your application is not vulnerable to the confused deputy problem. expires_inThe number of seconds left before the token becomes invalid. scopeA space-delimited list of scopes that the user granted access to. The list should match the scopes specified in your authorization request in step 1. useridThis value lets you correlate profile information from multiple Google APIs. It is only present in the response if you included the profile scope in your request in step 1. The field value is an immutable identifier for the logged-in user that can be used to create and manage user sessions in your application. The identifier is the same regardless of which client ID is used to retrieve it. This enables multiple applications in the same organization to correlate profile information. A sample response is shown below { "aud" "8819981768.apps.googleusercontent.com", "user_id" "123456789", "scope" "https //www.googleapis.com/auth/drive.metadata.readonly", "expires_in" 436 } If the token has expired, been tampered with, or had its permissions revoked, Google's authorization server returns an error message in the JSON object. The error surfaces as a 400 error and a JSON body in the format shown below. {"error" "invalid_token"} By design, no additional information is given as to the reason for the failure. Note In practice, a 400 error typically indicates that the access token request URL was malformed, often due to improper URL escaping. The JavaScript snippet below parses the response from Google's authorization server and then validates the access token. If the token is valid, the code stores it in the browser's local storage. You could modify the snippet to also send the token to your server as a means of making the token available to other API clients. var queryString = location.hash.substring(1); var params = {}; var regex = /([^ =]+)=([^ ]*)/g, m; while (m = regex.exec(queryString)) { params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]); // Try to exchange the param values for an access token. exchangeOAuth2Token(params); } /* Validate the access token received on the query string. */ function exchangeOAuth2Token(params) { var oauth2Endpoint = 'https //www.googleapis.com/oauth2/v3/tokeninfo'; if (params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('POST', oauth2Endpoint + '?access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { var response = JSON.parse(xhr.response); // Verify that the 'aud' property in the response matches YOUR_CLIENT_ID. if (xhr.readyState == 4 xhr.status == 200 response['aud'] response['aud'] == YOUR_CLIENT_ID) { localStorage.setItem('oauth2-test-params', JSON.stringify(params) ); } else if (xhr.readyState == 4) { console.log('There was an error processing the token, another ' + 'response was returned, or the token was invalid.') } }; xhr.send(null); } } Calling Google APIs JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account or service account. To do this, include the access token in a request to the API by including either an access_token query parameter or an Authorization Bearer HTTP header. When possible, the HTTP header is preferable, because query strings tend to be visible in server logs. In most cases you can use a client library to set up your calls to Google APIs (for example, when calling the Drive API). You can try out all the Google APIs and view their scopes at the OAuth 2.0 Playground. HTTP GET examples A call to the drive.files endpoint (the Drive API) using the Authorization Bearer HTTP header might look like the following. Note that you need to specify your own access token GET /drive/v2/files HTTP/1.1 Authorization Bearer access_token Host www.googleapis.com/ Here is a call to the same API for the authenticated user using the access_token query string parameter GET https //www.googleapis.com/drive/v2/files?access_token= access_token curl examples You can test these commands with the curl command-line application. Here's an example that uses the HTTP header option (preferred) curl -H "Authorization Bearer access_token " https //www.googleapis.com/drive/v2/files Or, alternatively, the query string parameter option curl https //www.googleapis.com/drive/v2/files?access_token= access_token JavaScript sample code The code snippet below demonstrates how to use CORS (Cross-origin resource sharing) to send a request to a Google API. This example does not use the Google APIs Client Library for JavaScript. However, even if you are not using the client library, the CORS support guide in that library's documentation will likely help you to better understand these requests. In this code snippet, the access_token variable represents the token you have obtained to make API requests on the authorized user's behalf. The complete example demonstrates how to store that token in the browser's local storage and retrieve it when making an API request. var xhr = new XMLHttpRequest(); xhr.open('GET', 'https //www.googleapis.com/drive/v3/about?fields=user ' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null); Complete example JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS This code sample demonstrates how to complete the OAuth 2.0 flow in JavaScript without using the Google APIs Client Library for JavaScript. The code is for an HTML page that displays a button to try an API request. If you click the button, the code checks to see whether the page has stored an API access token in your browser's local storage. If so, it executes the API request. Otherwise, it initiates the OAuth 2.0 flow. For the OAuth 2.0 flow, the page follows these steps It directs the user to Google's OAuth 2.0 server, which requests access to the https //www.googleapis.com/auth/drive.metadata.readonly scope. After granting (or denying) access, the user is redirected to the original page, which parses the access token from the query string. The page validates the access token and, if it is valid, executes the sample API request. The API request calls the Drive API's about.get method to retrieve information about the authorized user's Google Drive account. If the request executes successfully, the API response is logged in the browser's debugging console. You can revoke access to the app through the Permissions page for your Google Account. The app will be listed as OAuth 2.0 Demo for Google API Docs. To run this code locally, you need to set values for the YOUR_CLIENT_ID and REDIRECT_URI variables that correspond to your authorization credentials. The REDIRECT_URI should be the same URL where the page is being served. Your project in the Google API Console must also have enabled the appropriate API for this request. html head /head body script var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE'; var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE'; var queryString = location.hash.substring(1); // Parse query string to see if page request is coming from OAuth 2.0 server. var params = {}; var regex = /([^ =]+)=([^ ]*)/g, m; while (m = regex.exec(queryString)) { params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]); // Try to exchange the param values for an access token. exchangeOAuth2Token(params); } // If there's an access token, try an API request. // Otherwise, start OAuth 2.0 flow. function trySampleRequest() { var params = JSON.parse(localStorage.getItem('oauth2-test-params')); if (params params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('GET', 'https //www.googleapis.com/drive/v3/about?fields=user ' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null); } else { oauth2SignIn(); } } /* * Create form to request access token from Google's OAuth 2.0 server. */ function oauth2SignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https //accounts.google.com/o/oauth2/v2/auth'; // Create element to open OAuth 2.0 endpoint in new window. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id' YOUR_CLIENT_ID, 'redirect_uri' YOUR_REDIRECT_URI, 'scope' 'https //www.googleapis.com/auth/drive.metadata.readonly', 'state' 'try_sample_request', 'include_granted_scopes' 'true', 'response_type' 'token'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); } /* Verify the access token received on the query string. */ function exchangeOAuth2Token(params) { var oauth2Endpoint = 'https //www.googleapis.com/oauth2/v3/tokeninfo'; if (params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('POST', oauth2Endpoint + '?access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { var response = JSON.parse(xhr.response); // When request is finished, verify that the 'aud' property in the // response matches YOUR_CLIENT_ID. if (xhr.readyState == 4 xhr.status == 200 response['aud'] response['aud'] == YOUR_CLIENT_ID) { // Store granted scopes in local storage to facilitate // incremental authorization. params['scope'] = response['scope']; localStorage.setItem('oauth2-test-params', JSON.stringify(params) ); if (params['state'] == 'try_sample_request') { trySampleRequest(); } } else if (xhr.readyState == 4) { console.log('There was an error processing the token, another ' + 'response was returned, or the token was invalid.') } }; xhr.send(null); } } /script button onclick="trySampleRequest();" Try sample request /button /body /html Incremental authorization In the OAuth 2.0 protocol, your app requests authorization to access resources, which are identified by scopes. It is considered a best user-experience practice to request authorization for resources at the time you need them. To enable that practice, Google's authorization server supports incremental authorization. This feature lets you request scopes as they are needed and, if the user grants permission, add those scopes to your existing access token for that user. For example, an app that lets people sample music tracks and create mixes might need very few resources at sign-in time, perhaps nothing more than the name of the person signing in. However, saving a completed mix would require access to their Google Drive. Most people would find it natural if they only were asked for access to their Google Drive at the time the app actually needed it. In this case, at sign-in time the app might request the profile scope to perform basic sign-in, and then later request the https //www.googleapis.com/auth/drive.file scope at the time of the first request to save a mix. The following rules apply to an access token obtained from an incremental authorization The token can be used to access resources corresponding to any of the scopes rolled into the new, combined authorization. When you use the refresh token for the combined authorization to obtain an access token, the access token represents the combined authorization and can be used for any of its scopes. The combined authorization includes all scopes that the user granted to the API project even if the grants were requested from different clients. For example, if a user granted access to one scope using an application's desktop client and then granted another scope to the same application via a mobile client, the combined authorization would include both scopes. If you revoke a token that represents a combined authorization, access to all of that authorization's scopes on behalf of the associated user are revoked simultaneously. The code samples below show how to add scopes to an existing access token. This approach allows your app to avoid having to manage multiple access tokens. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS To add scopes to an existing access token, include the include_granted_scopes parameter in your request to Google's OAuth 2.0 server. The following code snippet demonstrates how to do that. The snippet assumes that you have stored the scopes for which your access token is valid in the browser's local storage. (The complete example code stores a list of scopes for which the access token is valid by setting the oauth2-test-params.scope property in the browser's local storage.) The snippet compares the scopes for which the access token is valid to the scope you want to use for a particular query. If the access token does not cover that scope, the OAuth 2.0 flow starts. Here, the oauth2SignIn function is the same as the one that was provided in step 2 (and that is provided later in the complete example). var SCOPE = 'https //www.googleapis.com/auth/drive.metadata.readonly'; var params = JSON.parse(localStorage.getItem('oauth2-test-params')); var current_scope_granted = false; if (params.hasOwnProperty('scope')) { var scopes = params['scope'].split(' '); for (var s = 0; s scopes.length; s++) { if (SCOPE == scopes[s]) { current_scope_granted = true; } } } if (!current_scope_granted) { oauth2SignIn(); // This function is defined elsewhere in this document. } else { // Since you already have access, you can proceed with the API request. } Revoking a token In some cases a user may wish to revoke access given to an application. A user can revoke access by visiting Account Settings. It is also possible for an application to programmatically revoke the access given to it. Programmatic revocation is important in instances where a user unsubscribes or removes an application. In other words, part of the removal process can include an API request to ensure the permissions granted to the application are removed. JS CLIENT LIBRARYOAUTH 2.0 ENDPOINTS To programmatically revoke a token, your application makes a request to https //accounts.google.com/o/oauth2/revoke and includes the token as a parameter curl -H "Content-type application/x-www-form-urlencoded" \ https //accounts.google.com/o/oauth2/revoke?token={token} The token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token will also be revoked. Note Google's OAuth 2.0 endpoint for revoking tokens supports JSONP and form submissions. It does not support Cross-origin Resource Sharing (CORS). If the revocation is successfully processed, then the status code of the response is 200. For error conditions, a status code 400 is returned along with an error code. The following JavaScript snippet shows how to revoke a token in JavaScript without using the Google APIs Client Library for JavaScript. Since the Google's OAuth 2.0 endpoint for revoking tokens does not support Cross-origin Resource Sharing (CORS), the code creates a form and submits the form to the endpoint rather than using the XMLHttpRequest() method to post the request. function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https //accounts.google.com/o/oauth2/revoke'; // Create form element to use to POST data to the OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'post'); form.setAttribute('action', revokeTokenEndpoint); // Add access token to the form so it is set as value of 'token' parameter. // This corresponds to the sample curl request, where the URL is // https //accounts.google.com/o/oauth2/revoke?token={token} var tokenField = document.createElement('input'); tokenField.setAttribute('type', 'hidden'); tokenField.setAttribute('name', 'token'); tokenField.setAttribute('value', accessToken); form.appendChild(tokenField); // Add form to page and submit it to actually revoke the token. document.body.appendChild(form); form.submit(); } Note Following a successful revocation response, it might take some time before the revocation has full effect.
https://w.atwiki.jp/gametips/pages/31.html
更新日時 2013-06-15 23 54 31 (Sat)アクセス数 - glDrawArrays 目次 概要 エラー サンプルコード 参考文献 概要 void glDrawArrays(GLenum mode, GLint first, GLsizei count); 属性配列からプリミティブのレンダリングを行います。 頂点インデックスを指定したい場合には glDrawElements を使用してください。 第 1 引数 mode では以下の定数を利用してプリミティブの種類を指定します。 定数 注釈 GL_POINTS GL_LINE_STRIP GL_LINE_LOOP GL_LINE_LINES GL_LINE_STRIP_ADJACENCY OpenGL 3.2 以上で利用できます GL_LINE_ADJACENCY OpenGL 3.2 以上で利用できます GL_TRIANGLE_STRIP GL_TRIANGLE_FAN GL_TRIANGLES GL_TRIANGLE_STRIP_ADJACENCY OpenGL 3.2 以上で利用できます GL_TRIANGLES_ADJACENCY OpenGL 3.2 以上で利用できます GL_PATCHES 第 2 引数 first には配列内の開始インデックスを指定します。 第 3 引数 count には要素数を指定します。 エラー GL_INVALID_ENUM 第 1 引数 mode が許可されている値でない場合に生成されます。 GL_INVALID_VALUE 第 3 引数 count が負である場合に生成されます。 GL_INVALID_OPERATION ジオメトリシェーダが有効で現在のプログラムが入力されたプリミティブタイプに互換性が無い場合に発生します generated if a non-zero buffer object name is bound to an enabled array and the buffer object s data store is currently mapped. サンプルコード 以下に、バッファオブジェクトを生成して頂点属性を転送する C++ コードの例を示します。 ///**********************************************//** /// 頂点属性を頂点シェーダに渡します。 /// ここではシェーダのコンパイルとリンクは省略されています。 ///**********************************************//** // バッファオブジェクトへのハンドル GLuint position_buffer; GLuint color_buffer; // 頂点配列オブジェクトへのハンドル GLuint vao; // バッファオブジェクトの生成 void CreateBufferObject() { // 三角形ポリゴンの位置と色に対応する頂点属性の定義 float positions[] = { -0.5f, -0.5f, 0.0f, 0.5f, -0.5f, 0.0f, 0.5f, 0.5f, 0.0f }; float colors[] = { 1.0f, 0.0f, 0.0f, 0.0f, 1.0f, 0.0f, 0.0f, 0.0f, 1.0f }; // バッファオブジェクトの生成 GLuint vbo[2]; glGenBuffers(2, vbo); position_buffer = vbo[0]; color_buffer = vbo[1]; // 頂点位置をバッファオブジェクトに転送 glBindBuffer(GL_ARRAY_BUFFER, position_buffer); glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 9, positions, GL_STATIC_DRAW); // 頂点色をバッファオブジェクトに転送 glBindBuffer(GL_ARRAY_BUFFER, color_buffer); glBufferData(GL_ARRAY_BUFFER, sizeof(float) * 9, colors, GL_STATIC_DRAW); } // 頂点シェーダの入力属性とバッファオブジェクトを対応付ける void BindVertexAttribute() { // 頂点シェーダの vertex_position と vertex_color に属性インデックス 0, 1 をマッピング glBindAttribLocation(program, 0, "vertex_position"); glBindAttribLocation(program, 1, "vertex_color"); // フラグメントシェーダの出力変数をマッピング glBindFragDataLocation(program, 0, "fragment_color"); // 頂点配列オブジェクトを 1 つ作成してバインド glGenVertexArrays(1, vao); glBindVertexArray(vao); // 頂点位置と頂点色のそれぞれについて頂点属性配列を有効化 glEnableVertexAttribArray(0); glEnableVertexAttribArray(1); // バッファオブジェクトに転送した頂点位置をインデックス 0 に関連付ける glBindBuffer(GL_ARRAY_BUFFER, position_buffer); glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte*)NULL); // バッファオブジェクトに転送した頂点色をインデックス 1 に関連付ける glBindBuffer(GL_ARRAY_BUFFER, color_buffer); glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 0, (GLubyte*)NULL); } // レンダリング void display() { glClear(GL_COLOR_BUFFER_BIT); glBindVertexArray(vao); glDrawArrays(GL_TRIANGLES, 0, 3); glFlush(); } 参考文献 OpenGLに関連するオススメの本や WEB サイトを紹介します． ページ右の画像をクリックすると Amazon で参考文献を購入できます． OpenGL策定委員会, 「OpenGLプログラミングガイド 原著第5版」, ピアソンエデュケーション OpenGLの赤本(Red Book)と呼ばれる定番の参考書の日本語版です。 少し値は張りますがOpenGLの基本的な使い方が丁寧にまとめられています。 初心者の方には敷居が高いかもしれませんがOpenGLを極めるつもりなら必須の教本だと思います。 Mark Segal, Kurt Akeley, Jon Leech, 「OpenGL4.0グラフィックスシステム」, カットシステム OpenGLの仕様書の日本語訳です。個人的には翻訳に違和感を覚えることはありませんでした。 英語が苦手な方は本書をAPIリファレンスの代わりに利用できます。 チュートリアルのような内容は含まれていませんので他の書籍との併用をオススメします。 床井 浩平, 「GLUTによるOpenGL入門」, 工学社 これから OpenGL を初めようとしている方にはこの本がオススメです。 おそらく OpenGL に関する文献の中では最も敷居が低く 3DCG に関する知識が全くなくても理解しやすいです。 少し内容は古いかもしれませんが導入という目的では最高の文献で、私もこの本から OpenGL に入門しました。 床井 浩平, 「GLUTによるOpenGL入門2 テクスチャマッピング」, 工学社 上の「GLUT によるOpenGL入門」の続編です。 前作の内容では物足りなかった方は本書を読むことで 3DCG の表現力が大幅に広がります。 引き続き平易な内容となっており、前作を読破した方であれば難なく理解できると思います。 David Wolff , 「OpenGL 4.0 シェーディング言語 -実例で覚えるGLSLプログラミング-」, ボーンデジタル 最近のゲームに見られるようなリアルな映像をつくりだすにはプログラマブル・シェーダという機能が欠かせません。 床井 浩平さんの「GLUTによるOpenGL入門2 テクスチャマッピング」でもシェーダに関しては少しだけ触れられていますが、書籍の後半で軽く紹介されているだけでいささか物足りない内容ではありますので、本格的に学ぶためにこの本の購入をオススメします。 OpenGL Reference Pages - glDrawArrays 公式の API リファレンス(英語)です。 質問・コメント欄 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/m_shige1979/pages/600.html
C C API 基本的なAPI 機能 摘要 my_init() グローバル変数およびスレッドに安全なプログラム中のスレッドハンドラーを初期化する mysql_affected_rows() 最後のUPDATE,DELETEまたはINSERTクエリーによって、負荷/削除/挿入された行の数を戻す mysql_autocommit() トグルスイッチを操作して、オートコミットモードをオンまたはオフにする mysql_change_user() オープン接続上のユーザーとデータベースを変更する mysql_close() サーバ接続を閉にする mysql_commit() コミット mysql_data_seek() クエリー結果セット中の任意の列ナンバーを探し求めます mysql_debug() 附与されたストリングを使ってDBUG_PUSHを実行します mysql_dump_debug_info() サーバにデバグ情報をログに書き込ませます mysql_errno() 最近取り出したMySQL機能に対するエラーのナンバーを戻します mysql_error() 最近取り出したMySQL機能に対するエラーのメッセージを戻します mysql_escape_string() SQLステートメントの中で使用するため、ストリング中で行う特別キャラクターのエスケープを行なう mysql_fetch_field() 次回のテーブルフィールトのタイプを戻します mysql_fetch_field_direct() フィールドナンバーを附与すると、テーブルフィールドのタイプを戻します mysql_fetch_fields() 全フィールド構造のアレーを戻します mysql_fetch_lengths() 現列中に全カラムの長さを戻します mysql_fetch_row() 結果セットから次列を持ってきます mysql_field_seek() カラムカーソルを規定カラム上に移動させます mysql_field_count() 最近のステートメントに対する結果のナンバーを戻します mysql_field_tell() 最後のmysql_fetch_field()に対して使用したフィールドカーソルの位置に戻します mysql_free_result() 結果セットによって使用されたメモリーを解放します mysql_get_client_info() クライアントバージョン情報をすとストリングとして戻します mysql_get_client_version() クライアントバージョン情報をすと整数として戻します mysql_get_host_info() 接続を述べたストリングを戻します mysql_get_server_version() サーバのナンバーを整数として戻します mysql_get_proto_info() 接続に使用したプロトコルバージョンを戻します mysql_get_server_info() サーバのバージョンナンバーを戻します mysql_info() 最近実効したクエリーに関する情報を戻します mysql_init() MYSQL構造を取得するか、初期化します mysql_insert_id() 前のクエリーによってAUTO_INCREMENTカラムに対して生成されたIDを戻します mysql_kill() 附与したスレッドを破壊します mysql_library_end() MySQL C APIライブラリーを最終承認します mysql_library_init() MySQL C APIライブラリーを初期化します mysql_list_dbs() シンプルなレギュラー表現にマッチするデータベースの名称を戻します mysql_list_fields() シンプルなレギュラー表現にマッチするフィールドの名称を戻します mysql_list_processes() 現サーバスレッドのリストを戻します mysql_list_tables() シンプルなリギュラー表現にマッチするテーブルの名称を戻します mysql_more_results() 更に結果が存在しているかチェックします mysql_next_result() 複数ステートメントの実効において、次結果を戻し、初期化します mysql_num_fields() 結果セット中のカラムのナンバーを戻します mysql_num_rows() 結果セット中の列のナンバーを戻します mysql_options() mysql_connect()に対する接続オプションをセットします mysql_ping() サーバへの接続が作動しているかチェックし、必要に応じて再接続します mysql_query() ゼロで終わるストリングとして規定されているSQLクエリーを実効します mysql_real_connect() MySQLサーバに接続します mysql_real_escape_string() 接続の現キャラクターセットを考慮して、SQLステートメント中で使用するストリング中に特別なキャラクターを使用することを避けます mysql_real_query() カウントストリングとして規定されているSQLクエリーを実効します mysql_refresh() テーブルとキャッシュをフラッシュするかリセットする mysql_reload() 供与されたテーブルを再び取り込むよう告げます mysql_rollback() ロールバック mysql_row_seek() mysql_row_tell()から戻った値を使って､結果セット中にから列オフセットを模索すします mysql_row_tell() 列カーソルの位置を戻します mysql_select_db() データベースを選択します mysql_server_end() MySQL C APIライブラリーを最終承認します mysql_server_init() MySQL C APIライブラリーを初期化します mysql_set_local_infile_default() LOAD DATA LOCAL INFILEハンドラーをその初期設定値にコールバックするようセットします mysql_set_local_infile_handler() アプリケーションに固有なLOAD DATA LOCAL INFILEハンドラーコールバックをインストールします mysql_set_server_option() 接続用オプション(multi-statementsを含む)をセットします mysql_sqlstate() 最後のエラーに対するSQLSTATEエラーコードを戻します mysql_shutdown() データベースサーバの操業を停止させます mysql_stat() サーバステータスをストリングとして戻します mysql_store_result() クライアントに対する結果セットを一式復元します mysql_thread_end() スレッドハンドラーを最終承認します mysql_thread_id() 現スレッドのIDを戻します mysql_thread_init() スレッドハンドラーを初期化します mysql_thread_safe() クライアントがスレッドに対して安全になるよう編集されている場合、１を戻します mysql_use_result() 列ごとに得られた結果セットを各々復元させる作業を開始させます mysql_warning_count() 以前のSQLステートメントに対する警告カウントを戻します Prepared C API 準備されたAPIでSQLを事前に登録することで、SQLの実行を高速化する 機能 説明 mysql_stmt_affected_rows() 準備されたUPDATE、DELETE、またはINSERT ステートメントの行変更、消去、もしくは挿入の回数を返す。 mysql_stmt_attr_get() 準備されたステートメントの属性値を入手する。 mysql_stmt_attr_set() 準備されたステートメントの属性をセットする。 mysql_stmt_bind_param() 準備されたＳＱＬステートメントのパラメータマーカとアプリケーションデータバッファを関連させる。 mysql_stmt_bind_result() 結果セットのカラムとアプリケーションデータバッファを関連させる。 mysql_stmt_close() 準備されたステートメントに使用されているメモリを開放する。 mysql_stmt_data_seek() ステートメント結果セットの任意の行ナンバーをシークする。 mysql_stmt_errno() 最後に実行されたステートメントに対してエラーナンバーを返す。 mysql_stmt_error() 最後に実行されたステートメントに対してエラーメッセージを返す。 mysql_stmt_execute() 準備されたステートメントを実行する。 mysql_stmt_fetch() 結果セットから次のデータの行を入手し、全ての束縛されたカラムのデータを返す。 mysql_stmt_fetch_column() 結果セットの現在の行の１カラムからデータを入手する。 mysql_stmt_field_count() 最近のステートメントの結果カラムの数を返す。 mysql_stmt_free_result() ステートメントハンドルに割り当てられたリソースを開放する。 mysql_stmt_init() MYSQL_STMT 構成のためのメモリを確保し、初期化する。 mysql_stmt_insert_id() 準備されたプログラムに夜AUTO_INCREMENT カラム用に生成されたＩＤを返す。 mysql_stmt_num_rows() ステートメントのバッファされた結果セットからトータル行を返す。 mysql_stmt_param_count() 準備されたＳＱＬステートメント内のパラメータの数を返す。 mysql_stmt_param_metadata() (結果セットの形でパラメータメタデータを返す。)現在、この機能は何もしません。 mysql_stmt_prepare() は実行のため、SQLストリングを用意します。 mysql_stmt_reset() Reset the statement buffers in the server. mysql_stmt_result_metadata() Returns prepared statement metadata in the form of a result set. mysql_stmt_row_seek() Seeks to a row offset in a statement result set, using value returned from mysql_stmt_row_tell(). mysql_stmt_row_tell() Returns the statement row cursor position. mysql_stmt_send_long_data() Sends long data in chunks to server. mysql_stmt_sqlstate() Returns the SQLSTATE error code for the last statement execution. mysql_stmt_store_result() Retrieves the complete result set to the client.
https://w.atwiki.jp/api_programming/
主には自分の覚書のため。詰まったところと回避策を、思い出したようにまたやり始める自分に残す。 最近は TiddlyWiki が便利すぎて、そっちに乗り換え中。ここに書く意味が少なくなってしまった。 下位ページ Content 言語 サイト、api その他 言語 JavascriptJavascript/jQuery/Javascript/jQuery Mobile HTML・CSS Java Python サイト、api CheckVist Toodledo Remember The Milk Google カーリル その他 その他 Eclipse JSON monaca Connect IQ Raspberry Pi ウェブスクレイピング 生産性向上 自動化 Remember The Milk関連の忘備録 下位ページ
https://w.atwiki.jp/suffix/pages/179.html
Google AJAX APIの利用 Mapベーシック GoogleMapsAPIのリンク ここでマップデザインの概要が確認できる。 http //koti.mbnet.fi/ojalesa/exam/design_aid.html tempメモURL http //www.rfs.jp/sb/javascript/10/googlemaps_v2.html http //chikura.fprog.com/index.php?UID=1165466955 http //www.geekpage.jp/web/google-maps-api/gmapcreator/
https://w.atwiki.jp/pspprogram/pages/33.html
機能 pcmデータを出力します。 channelで指定したチャンネルが再生中の場合、その再生が終わるのを待ちます。 API int sceAudioOutputBlocking(int channel, int vol, void *buf); 第一引数 sceAudioChReserveで初期化割り当てしたチャンネルナンバー 第二引数 ボリューム。 headerで#define PSP_AUDIO_VOLUME_MAX 0x8000 とされているので、これが使える。 第三引数 実際のpcmデータを入れたポインタを渡す。 44.1k、16bit、stereoの。 waveファイルのformatと同じです。 なので、wavファイル開いてちょちょっと やればあとはそのままファイル読んで この関数に横流ししませう。 戻り値 多分ほかと同じで 0で成功 使用例 PlayNoiseForeverをコールすると、雑音を無限に再生し続けるサンプルです。 注意 未テストです。 #include pspaudio.h #include stdlib.h #define SAMPLES 1024 /* バッファサイズ */ short buffer[2][SAMPLES][2]; void SynthWaveform(short *wave){ /* 音を合成します */ int n; for(n=0;n SAMPLES*2;n++) wave[n]=rand(); /* ホワイトノイズジェネレータ */ } void PlayNoiseForever(){ /* 雑音を永遠に再生 */ int bufidx=0; int chan=sceAudioChReserve(); while(1){ SynthWaveform(buffer[bufidx]); sceAudioOutputBlocking(chan, PSP_VOLUME_MAX, buffer[bufidx]); bufidx=1-bufidx; } }
https://w.atwiki.jp/cscd/pages/252.html
Getting Started with the Evernote API - Evernote Developers コメント 名前 コメント すべてのコメントを見る
https://w.atwiki.jp/api_programming/pages/237.html
google cloud を使ってみるただjavascriptで動かすぐらいならここで作る必要はない。 今後、servletやらで動かすことを考えて、ここで動かす。 本音は、昔使っていたから。 test用のボタンを置いて、アラート表示だけの簡易ページ作成 html form, input(button) javascrpit function, alert() jQueryを準備するjQuery corsの壁が超えられないので、javaのservletで、toodledoへのアクセス用のpost処理を作る受け取ったパラメータをそのまま渡す。反対に帰ってきたレスポンスをそのまま返すだけ。 https //www54.atwiki.jp/api_programming/pages/64.html#id_c6d9a5f2 https //www54.atwiki.jp/api_programming/pages/61.html#id_7f0444d5 リダイレクト処理のページを先に作る。Toodledoの認証の流れが下記のため。Toodledoの認証ページへリダイレクトして処理 redirect先でcode受け取り ... リダイレクト処理ページにパラメータ処理（code読み取り）を実装する。 $.ajax(), toodledoのレスポンスが受けられるか、確認する←だめだった。 redirectのページのパラメータを使って、servletからpostするように実装する。 リダイレクト処理ページにcookie登録処理をつける。とりあえず、テストパラメータを設定して、これをcookieに登録 ToodledoAccessToken, ToodledoRefreshTokenとして登録する https //www54.atwiki.jp/api_programming/pages/40.html#id_7599b927 javascript document.cookie toodledo.htmlから、アクセストークンを使って、タスクをただ取ってくる処理を付けるとりあえず、ボタンで呼び出す。 この時点では、JSONも、ただの文字列として表示するだけ。 この時点で、servlet側の処理をいじって、servletに渡すパラメータとｈして、"auth"か"get"かで処理を振り分ける処理を追加。 タスクを取ってきたあとに、タスク一つ一つを表示する refresh_tokenを使って、access_tokenを再取得する処理を付けるservlet側の処理の振り分けに auth, get, refresh の三種に変更 java switch文