1.Subscribe to Basicの下に「Sign up for FreeAccount」があるのでそれをクリック
2.Describe all of your use cases of Twitter’s data and APIの部分に利用方法を書いた。
I want to use the API to republish my own tweets on my blog. I will store my tweets, image URLs, and dates in a spreadsheet. I will appropriately edit and augment the content of the tweets as needed. I will manually post the edited tweets and images on my blog.
3.チェックボックスにチェックを入れた
- You understand that you may not resell anything you receive via the Twitter APIs
- You understand your Developer account may be terminated if you violate the Developer Agreement or any of the Incorporated Developer Terms
- You accept the Terms & Conditions
4.Dashboardが出てきた。
5.Dashboard>自分のアプリプロジェクト>Keys and tokensタブ
・Consumer Keys
このテキストは、Twitter Developer Dashboard内で、あなたのアプリケーションのAPIキーとAPIシークレット(Secret)に関する説明です。具体的には以下のような意味を持っています:
API Key and Secret: これらは、APIリクエストを行う際にあなたのアプリケーションを認証するために使用される重要な情報です。APIキーとシークレットは、アプリケーションの「ユーザー名」と「パスワード」のようなものと考えることができます。
Reveal API Key hint: このオプションを使用すると、APIキーの一部を確認することができます。これは、キーを忘れた場合や確認が必要な場合に役立ちます。
Regenerate: このオプションを使用すると、新しいAPIキーとシークレットを生成できます。これは、セキュリティ上の理由で現在のキーを無効にして新しいものに交換する必要がある場合に使用されます。
APIキーの最後の6文字を常に表示できますが、シークレットは永久に隠されたままです:これはセキュリティ対策の一環です。APIシークレットは非常に重要な情報であり、第三者に漏れるとアプリケーションのセキュリティが脅かされるため、完全には表示されません。しかし、APIキーの一部を見ることで、どのキーがどのアプリケーションに関連しているかを確認するのに役立ちます。
これらの認証情報は、Twitter APIを使用する際に重要であり、アプリケーションがTwitterのデータに安全にアクセスできるようにするためのものです。セキュリティを保つためにも、これらの情報は慎重に管理し、必要に応じて適切な対策を講じることが重要です。
・Authentication Tokens
このテキストは、「認証トークン」と「Bearer Token」に関する説明です。具体的には以下のような内容を意味します:
- Authentication Tokens: 認証トークンは、APIリクエストを行う際に、そのリクエストが正当なものであることを証明するために使用されるトークンです。
- Bearer Token: Bearer Tokenは、特定の認証トークンの一種で、あなたの開発者アプリケーションに代わってリクエストを認証するために使用されます。
- Generate: 「Generate」オプションを使用すると、新しいBearer Tokenを生成することができます。これは、APIリクエストを認証するために必要なトークンを取得するために使用されます。
Bearer Tokenは、HTTPリクエストのAuthorizationヘッダーに含めることで、そのリクエストがあなたのアプリケーションから送信されたものであることをTwitter APIに伝えます。これにより、APIはリクエストが正当であることを確認し、適切なデータやサービスへのアクセスを提供できるようになります。
簡単に言うと、Bearer TokenはあなたのアプリケーションがTwitter APIを使用して情報を取得したり、操作を行ったりする際に、そのアプリケーションを認証するための重要なキーです。
・Access Token and Secret
- Access Token and Secret: アクセストークンとシークレットは、OAuth 1.0a認証を使用してAPIリクエストを認証するためのユーザー固有の資格情報です。これらは、あるリクエストが特定のユーザーアカウント(Xアカウント)を代表して行われることを示します。
アクセストークンとシークレットは、Twitter APIを使用する際に、特定のTwitterユーザーのアクションを行うための認証に用いられます。これにより、アプリケーションがそのユーザーの許可を得てアクションを実行できるようになります。たとえば、ユーザーのツイートを投稿したり、タイムラインを取得したりする場合に、これらの認証情報が使用されます。
OAuth 1.0a認証プロセスでは、アクセストークンとシークレットの組み合わせが重要で、これによりセキュアな認証が可能になります。アクセストークンはそのユーザーがアプリケーションに特定の権限を付与したことを示し、シークレットはそのトークンを保護するために使用されます。これらは一緒に使われることで、APIリクエストが正確にそのユーザーからのものであることを確認します。
・User authentication settings
・App permissions
このテキストは、アプリケーションがOAuth 1.0a認証を使用してユーザーから特定の権限を要求する際の説明です。具体的には、以下のような権限があります。
- Read (読み取り): この権限を持つアプリは、ツイートやプロファイル情報を読み取ることができます。これは、ユーザーの公開情報にアクセスするための基本的な権限です。
- Read and write (読み取りと書き込み): この権限には、「読み取り」権限の全ての機能に加えて、ツイートの投稿やプロファイル情報の変更ができる能力が含まれます。アプリがユーザーの代わりにツイートを投稿するなどの機能を持つ場合に必要です。
- Read and write and Direct message (読み取り、書き込み、ダイレクトメッセージ): これには「読み取りと書き込み」の全ての機能に加えて、ダイレクトメッセージを読み取り、投稿する能力が含まれます。これにより、アプリはプライベートなメッセージを管理できるようになります。
- Request email from users (ユーザーからのメールアドレスの要求): アプリがユーザーのメールアドレスを要求する場合、アプリのプライバシーポリシーと利用規約へのURLを提供する必要があります。これは、ユーザーのプライバシーを保護し、アプリがどのようにユーザー情報を使用するかを透明にするための措置です。
これらの権限は、アプリがユーザーのTwitterアカウントとどのように対話するかを定義します。ユーザーは、アプリが自分の情報やアカウントにアクセスする前に、これらの権限を明示的に承認する必要があります。
・Type of app
Twitter APIの認証設定画面における「Type of App」は、アプリケーションがどのような種類のクライアントであるかを示し、それに基づいてOAuth 2.0認証を使用するための設定を行います。具体的には、以下の2つのカテゴリに分かれています。
Native App (ネイティブアプリ)
Public client (公開クライアント): ネイティブアプリは、主にスマートフォンやデスクトップアプリケーションなど、エンドユーザーのデバイス上で直接実行されるアプリケーションを指します。これらは「公開クライアント」と見なされ、クライアント秘密を安全に保持することが難しいため、リダイレクトベースのフローやデバイスフローなどの特定の認証フローを使用して認証を行います。
Web App, Automated App or Bot (ウェブアプリ、自動化アプリ、またはボット)
Confidential client (機密クライアント): このカテゴリには、サーバー上で動作するウェブアプリケーションや、自動化されたタスクを実行するアプリケーション、ボットが含まれます。これらは「機密クライアント」と見なされ、クライアント秘密(アプリケーションの秘密キーなど)を安全にサーバー上で保持できるため、よりセキュアな認証フローが可能です。この種類のアプリケーションは、クライアント認証を使用してトークンを安全に交換することができます。
・App info
・Callback URI / Redirect URL ★必須
このURLは、Twitterからの認証後、ユーザーがリダイレクトされる場所です。App Scriptを使用している場合、Googleスクリプトが提供するWebアプリのURL(https://script.google.com/macros/s/…の形式)や、認証情報を処理するための専用のハンドラーURLを設定します。例えば、https://script.google.com/macros/s/YOUR_SCRIPT_ID/execのようになります。
App Script>デプロイ>Webアプリ>デプロイで出たURLとか?
左側の歯車ボタン>プロジェクトの設定>スクリプトIDをコピーして、https://script.google.com/macros/d/スクリプトID/usercallbackとして文字列を貼り付けるか?
どっちかわからん。
・Website URL ★必須
アプリケーションの主なウェブサイトまたは、App Scriptプロジェクトの説明を掲載したページのURLを入力します。これはユーザーがアプリケーションについて更に情報を得るためのリンクとして機能します。持っていない場合はGoogleドライブ>新規作成>Googleサイトで無料で作成してURLを出力すればよいと思う。
例: https://your-application-website.com
・Organization name
アプリケーションを開発している組織または個人の名前を入力します。この名前は、ユーザーがアプリケーションの認証を行う際に表示されます。
例: Your Organization Name
・Organization URL
組織のウェブサイトURLを入力します。これは、ユーザーが組織について更に詳しく知るためのリンクとして機能します。
例: https://your-organization-website.com
・Terms of Service
アプリケーションの利用規約のページへのリンクを提供します。これはオプションですが、ユーザーがアプリケーションを使用する際のルールや条件を明確にするために推奨されます。
例: https://your-application-website.com/terms
・Privacy Policy
アプリケーションのプライバシーポリシーのページへのリンクを提供します。ユーザーのデータがどのように扱われるかを説明することは非常に重要です。
例: https://your-application-website.com/privacy
これらの設定を適切に行うことで、ユーザーがアプリケーションの認証プロセスをスムーズに進めることができるようになります。
入力したら次のメッセージが出た。
Here is your OAuth 2.0 Client ID and Client Secret
For security, this will be the last time we’ll fully display the Secret.
Save it in a secure location
Treat it like a password or a set of keys
If security has been compromised, regenerate it
DO NOT store it in public places or shared docs
このメッセージは、OAuth 2.0認証を使用するために必要な「クライアントID」と「クライアントシークレット」を提供しており、それらの扱い方に関するセキュリティ上の指示を含んでいます。意味するところは以下の通りです:
- クライアントIDとクライアントシークレットが提供されています。 これらは、あなたのアプリケーションがOAuth 2.0認証を通じてサービスプロバイダ(例えばTwitter)と安全に通信するために必要な識別情報です。
- シークレットはこれが最後の表示となります。 セキュリティ上の理由から、クライアントシークレットはこのメッセージでのみ全文が表示され、以後は表示されないことを意味しています。なので、紛失しないように安全な場所に保存する必要があります。
- 安全な場所に保存するよう指示しています。 クライアントシークレットは非常に重要な情報であり、不正アクセスを防ぐために、パスワードや鍵セットのように慎重に扱う必要があります。
- セキュリティが侵害された場合は再生成すること。 もしクライアントシークレットが漏洩したり、セキュリティが侵害された疑いがある場合は、直ちに新しいシークレットを生成し、古いものは使用しないようにする必要があります。
- 公開場所や共有ドキュメントに保存しないこと。 クライアントシークレットは公開されるべき情報ではなく、GitHubの公開リポジトリや共有ドキュメントなど、第三者からアクセス可能な場所には絶対に保存しないように指示しています。
要するに、このメッセージはクライアントIDとクライアントシークレットの重要性と、それらを安全に管理するためのベストプラクティスを伝えています。この2つをコピーして保存して完了。
Twitter APIが動かない。エラーが出る。
{client_id=123456789, reason=client-not-enrolled, registration_url=https://developer.twitter.com/en/docs/projects/overview, title=Client Forbidden, required_enrollment=Appropriate Level of API Access, type=https://api.twitter.com/2/problems/client-forbidden, detail=When authenticating requests to the Twitter API v2 endpoints, you must use keys and tokens from a Twitter developer App that is attached to a Project. You can create a project via the developer portal.}
エラーの内容
- Client ID: エラーが発生したクライアントIDを示しています。
- Reason:
client-not-enrolled
– このクライアントは、必要なレベルのAPIアクセス権を持っていないため、リクエストを処理できません。 - Registration URL: Twitterの開発者ポータルでプロジェクトを作成するためのURLが提供されています。
- Title:
Client Forbidden
– クライアントにはAPIへのアクセス権がない、またはアクセスが禁止されていることを示します。 - Required Enrollment:
Appropriate Level of API Access
– 適切なレベルのAPIアクセス権が必要であることを示しています。 - Type: エラーの種類を示すURLが提供されています。
- Detail: Twitter API v2エンドポイントへのリクエストを認証するためには、プロジェクトに紐付けられたTwitter開発者アプリからのキーとトークンを使用する必要があります。開発者ポータルを通じてプロジェクトを作成できます。