トップ Google Apps Scriptに関する質問複製したGASで、AmazonSPAPIの認可フローを完了する

編集履歴

回答編集履歴

追記

2022/05/03 20:10

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -1,4 +1,7 @@
 **＜下記は「試みたものの、結果としてはうまくいなかった例」になりますが、試行の過程として残しています。修正後の内容は、後述の「追記２」を参照してください＞**
+また、以下は、Amazon SP-API上での検証ではなく、他の一般的なOAuth2.0アプリケーションでの検証になります。
 コピー元のスクリプトに doGet() を実装してWebアプリとしてデプロイし、コピー先からコピー元に対して、認証に必要な処理を呼び出せるようにしてはいかがでしょうか。
 + DEPLOY_URL は、一度コピー元をデプロイして確定してしまえば、変更がない限りコピー先で変更する必要はありません。（コピー先ファイルごとのデプロイURLに変える必要はありません。）

2022/05/01 06:05

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -224,8 +224,8 @@
 # 追記
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
-+ ①originalを所有(作成)しているGoogleアカウント以外のアカウントが、コピーしたファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）
++ ①originalを所有(作成)しているGoogleアカウント**以外**のアカウントが、コピーしたファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）
-（①[オリジナル]を所有（作成）しているアカウントが ②[コピー]を実行する場合は認証フローを完了できる）
+（①[オリジナル]を所有（作成）しているGoogleアカウントであれば ②[コピー]のshowDialogを実行しても問題なく認証フローを完了できる）
 これは、オリジナルとコピー両方公開ファイルにしても変わりません。
 （おそらくGASまたはOAuth2.0の仕組み上不可避と思われます）

2022/05/01 06:04

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -225,6 +225,7 @@
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
 + ①originalを所有(作成)しているGoogleアカウント以外のアカウントが、コピーしたファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）
+（①[オリジナル]を所有（作成）しているアカウントが ②[コピー]を実行する場合は認証フローを完了できる）
 これは、オリジナルとコピー両方公開ファイルにしても変わりません。
 （おそらくGASまたはOAuth2.0の仕組み上不可避と思われます）

2022/05/01 05:29

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -224,12 +224,13 @@
 # 追記
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
-+ ①を所有(作成)しているGoogleアカウント以外のアカウントが ②のファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）
++ ①originalを所有(作成)しているGoogleアカウント以外のアカウントが、コピーしたファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）
-これは、①と②両方公開ファイルにしても変わりません。
+これは、オリジナルとコピー両方公開ファイルにしても変わりません。
 （おそらくGASまたはOAuth2.0の仕組み上不可避と思われます）
+一方、一部ではうまく行っています。
-+ ①での認証・認可後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
++ ①[オリジナル]での認証・認可後、オリジナルを所有（作成）しているアカウント以外のアカウントが ②[コピー]を利用して①[オリジナル]からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは可能。
-+ ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
++ ①からもらったアクセストークンが揮発した場合でも、①から自動的に更新後のアクセストークンを取得できる。
 したがって、少なくとも最初の認証・認可フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。

2022/05/01 05:24

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -1,4 +1,5 @@
+**＜下記は「試みたものの、結果としてはうまくいなかった例」になりますが、試行の過程として残しています。修正後の内容は、後述の「追記２」を参照してください＞**
-下記のように、doGet() を実装して、コピー先からコピー元に対して、認証に必要な処理を呼び出せるようにしてはいかがでしょうか。
+コピー元のスクリプトに doGet() を実装してWebアプリとしてデプロイし、コピー先からコピー元に対して、認証に必要な処理を呼び出せるようにしてはいかがでしょうか。
 + DEPLOY_URL は、一度コピー元をデプロイして確定してしまえば、変更がない限りコピー先で変更する必要はありません。（コピー先ファイルごとのデプロイURLに変える必要はありません。）

2022/05/01 02:17

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -225,7 +225,7 @@
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
 + ①を所有(作成)しているGoogleアカウント以外のアカウントが ②のファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）
 これは、①と②両方公開ファイルにしても変わりません。
-（おそらくGASまたはOauth2の仕組み上不可避と思われます）
+（おそらくGASまたはOAuth2.0の仕組み上不可避と思われます）
 + ①での認証・認可後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
 + ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。

2022/05/01 01:43

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -337,5 +337,5 @@
 }
 ```
-ただし、現状のコードだと、DEPLOY_URLを第三者に知られてしまうと、その人がアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみ（GET時のパラメータに特別なトークンが埋め込まれていないとアクセストークンを発行できないようにする等）が別途必要かもしれません。
+ただし、現状の単純なコードでは、DEPLOY_URLを第三者に知られてしまうと、その人がアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみ（GET時のパラメータに特別なトークンが埋め込まれていないとアクセストークンを発行できないようにする等）を実装することが必要です。
-（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも利用者セラーに知られてしまうのが問題です）
+（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだと認証に必要なclient_id や client_secret まで利用者セラーに知られてしまうのが問題だと思います）

2022/05/01 01:41

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -337,5 +337,5 @@
 }
 ```
-ただし、現状のコードだと、DEPLOY_URLを第三者に知られてしまうと、その人がアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみ（post時に別のトークンを埋め込んで識別する等）が別途必要かもしれません。
+ただし、現状のコードだと、DEPLOY_URLを第三者に知られてしまうと、その人がアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみ（GET時のパラメータに特別なトークンが埋め込まれていないとアクセストークンを発行できないようにする等）が別途必要かもしれません。
 （この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも利用者セラーに知られてしまうのが問題です）

2022/05/01 01:39

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -223,14 +223,14 @@
 # 追記
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
-+ ①を所有(作成)しているGoogleアカウント以外のアカウントが ②のファイルから showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
++ ①を所有(作成)しているGoogleアカウント以外のアカウントが ②のファイルから showDialog を実行した場合、認可フローを完了させることができない（トークンが無効または期限が切れていると表示される）
 これは、①と②両方公開ファイルにしても変わりません。
 （おそらくGASまたはOauth2の仕組み上不可避と思われます）
-+ ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
++ ①での認証・認可後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
 + ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
-したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
+したがって、少なくとも最初の認証・認可フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
@@ -238,8 +238,8 @@
 # 追記２
 結局、運用方針としては、下記のように①と②を分離し、
-+ ①は開発者／管理者が専有してメンテナンス（最初だけ認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
++ ①は開発者／管理者が専有してメンテナンス（最初だけ認証・認可を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
-+ 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
++ 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証・認可フローは不要）
 というのが現実的かもしれませんね。
 crient_secret が書かれたファイルをむやみに渡す必要がなくなるというメリットもあると思います。
@@ -293,7 +293,7 @@
 ②改
 実際の処理を行うファイル。こちらを複製してセラーにつかってもらう。
-利用者セラーは認証フローを行わない前提のため、showDialogは①へ移動した。
+利用者セラーは認証・認可フローを行わない前提のため、showDialogは①へ移動した。
 こちらは特にデプロイする必要はない。
 ```js
 const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL

2022/05/01 01:35

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -223,8 +223,10 @@
 # 追記
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
-+ ①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）（これはおそらくOauth2の仕組み上不可避と思われます）
++ ①を所有(作成)しているGoogleアカウント以外のアカウントが ②のファイルから showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
 これは、①と②両方公開ファイルにしても変わりません。
+（おそらくGASまたはOauth2の仕組み上不可避と思われます）
 + ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
 + ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。

2022/05/01 01:34

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -229,8 +229,11 @@
 + ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
 したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
----
 # 追記２
 結局、運用方針としては、下記のように①と②を分離し、
 + ①は開発者／管理者が専有してメンテナンス（最初だけ認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）

2022/05/01 01:32

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -223,7 +223,7 @@
 # 追記
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
-・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）（これはおそらくOauth2の仕組み上不可避）
++ ①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）（これはおそらくOauth2の仕組み上不可避と思われます）
 これは、①と②両方公開ファイルにしても変わりません。
 + ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
 + ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。

2022/05/01 01:31

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -223,14 +223,16 @@
 # 追記
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
-・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
+・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）（これはおそらくOauth2の仕組み上不可避）
 これは、①と②両方公開ファイルにしても変わりません。
 + ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
 + ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
 したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
+---
+# 追記２
-運用方針として、下記のように①と②を分離し、
+結局、運用方針としては、下記のように①と②を分離し、
 + ①は開発者／管理者が専有してメンテナンス（最初だけ認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
 + 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
 というのが現実的かもしれませんね。

2022/05/01 01:30

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -330,5 +330,5 @@
 }
 ```
-ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
+ただし、現状のコードだと、DEPLOY_URLを第三者に知られてしまうと、その人がアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみ（post時に別のトークンを埋め込んで識別する等）が別途必要かもしれません。
 （この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも利用者セラーに知られてしまうのが問題です）

2022/05/01 01:28

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -331,4 +331,4 @@
 ```
 ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
-（ただし、この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも利用者セラーに知られてしまうのが問題です）
+（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも利用者セラーに知られてしまうのが問題です）

2022/05/01 01:28

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -230,15 +230,13 @@
 したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
-運用方針として、①と②を分離し、
+運用方針として、下記のように①と②を分離し、
 + ①は開発者／管理者が専有してメンテナンス（最初だけ認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
 + 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
 というのが現実的かもしれませんね。
 crient_secret が書かれたファイルをむやみに渡す必要がなくなるというメリットもあると思います。
-ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
-（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも明記されてしまっているのが問題）
 ①改（認証・認可用ファイル。showDialogを元に戻した）。デプロイし、デプロイＵＲＬを②改に記載する。
 ```js
@@ -331,4 +329,6 @@
   console.log(orders);
 }
 ```
+ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
+（ただし、この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも利用者セラーに知られてしまうのが問題です）

2022/05/01 01:26

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -240,7 +240,7 @@
 ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
 （この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも明記されてしまっているのが問題）
-①改（認証・認可用ファイル。showDialogを元に戻した）
+①改（認証・認可用ファイル。showDialogを元に戻した）。デプロイし、デプロイＵＲＬを②改に記載する。
 ```js
 AUTH_ENDPOINT = 'https://XXX';
 TOKEN_ENDPOINT = 'https://YYY';
@@ -286,7 +286,10 @@
 ```
+②改
+実際の処理を行うファイル。こちらを複製してセラーにつかってもらう。
-②改’（実際の処理を行うファイル。こちらを複製してセラーにつかってもらう。セラーは認証フローを行わない前提のため、showDialogは①へ移動）
+利用者セラーは認証フローを行わない前提のため、showDialogは①へ移動した。
+こちらは特にデプロイする必要はない。
 ```js
 const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL

2022/05/01 01:23

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -286,7 +286,7 @@
 ```
-②改’（実際の処理を行うファイル。こちらを複製。showDialogは①へ移動）
+②改’（実際の処理を行うファイル。こちらを複製してセラーにつかってもらう。セラーは認証フローを行わない前提のため、showDialogは①へ移動）
 ```js
 const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL

2022/05/01 01:22

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -89,169 +89,6 @@
   output.setContent(JSON.stringify(content));
   return output;
 }
-```
------
-# 説明
-上記は、実質的には下記の２つのコードを合体したものになります。
-① original.gs
-・認証・認可の処理を行う専用のファイル。
-・アクセストークンを保管するとともに、②からの要求に応じて authorizationUrl やアクセストークンを渡す。
-```js
-AUTH_ENDPOINT = 'https://XXX';
-TOKEN_ENDPOINT = 'https://YYY';
-CLIENT_ID = 'AAA';
-CLIENT_SECRET = 'BBB';
-APP_ID = 'CCC';
-// OAuth2ライブラリ使用
-function getService() {
-　略
-}
-function authCallback(request) {
-　略
-}
-function doGet(e) {
-  if (e.parameter.authmode)
-    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })
-  if (getService.hasAccess())
-    return toJson({ authorized: true, token: getService.getAccessToken() })
-  return toJson({ authorized: false })
-}
-function toJson(content) {
-　略
-}
-```
-② copy.gs
-・実際の処理を行うファイル
-```js
-const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL
-/**
- * 認証用ダイアログ（html）表示
- * セラーセントラルの認証URLへリンクさせる
- */
-function showDialog() {
-  const respjson = UrlFetchApp.fetch(DEPLOY_URL + '?authmode=true').getContentText();
-  const response = JSON.parse(respjson);
-  const url = response.authorizationUrl;
-  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
-  const html = HtmlService.createHtmlOutput(tag_text);
-  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
-}
-/**
- * アクセストークンを取得する。
- */
-function getToken() {
-  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
-  const response = JSON.parse(respjson);
-  if (response.authorized) {
-    return response.token;
-  } else {
-    return "UNAUTHORIZED"
-  }
-}
-```
-上記のように２つに分けた場合は、①単独では動かず、②の copy.js を複製して使用することを想定しています。
-（冒頭に記載したコードは、①と②を合体したものですので、単一のファイルだけで動くはずです）
-②で認証・認可が必要になる場面で ①を呼び出して認証・認可に必要な処理を肩代わりさせます。
-この過程でアクセストークンを ①の中に保管しておきます。
-実際に②がいろいろな処理を行う場面でアクセストークンが必要になった場合は、getToken()によって①からアクセストークンを取得する、という考え方です。
------
-# 追記
-他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
-・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
-これは、①と②両方公開ファイルにしても変わりません。
-+ ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
-+ ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
-したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
-運用方針として、①と②を分離し、
-+ ①は開発者／管理者が専有してメンテナンス（最初だけ認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
-+ 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
-というのが現実的かもしれませんね。
-crient_secret が書かれたファイルをむやみに渡す必要がなくなるというメリットもあると思います。
-ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
-（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも明記されてしまっているのが問題）
-①改（認証・認可用ファイル。showDialogを元に戻した）
-```js
-AUTH_ENDPOINT = 'https://XXX';
-TOKEN_ENDPOINT = 'https://YYY';
-CLIENT_ID = 'AAA';
-CLIENT_SECRET = 'BBB';
-APP_ID = 'CCC';
-// OAuth2ライブラリ使用
-function getService() {
-　略
-    .setLock(LockService.getUserLock());
-}
-function authCallback(request) {
-　略
-}
-function doGet(e) {
-  if (e.parameter.authmode)
-    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })
-  if (getService.hasAccess())
-    return toJson({ authorized: true, token: getService.getAccessToken() })
-  return toJson({ authorized: false })
-}
-function toJson(content) {
-　略
-}
-/**
- * 認証用ダイアログ（html）表示
- * セラーセントラルの認証URLへリンクさせる
- */
-function showDialog(){
-  const service = getService();
-  const url = service.getAuthorizationUrl();
-  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
-  const html = HtmlService.createHtmlOutput(tag_text);
-  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
-}
-```
-②改’（実際の処理を行うファイル。こちらを複製。showDialogは①へ移動）
-```js
-const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL
-/**
- * アクセストークンを取得する。
- */
-function getToken() {
-  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
-  const response = JSON.parse(respjson);
-  if (response.authorized) {
-    return response.token;
-  } else {
-    return "UNAUTHORIZED"
-  }
-}
 /*個別処理を行う場合に必要となるアクセストークンは、getToken() で取得する。
  * 下記は注文を取得する例。
@@ -279,3 +116,216 @@
 }
 ```
+-----
+# 説明
+上記は、実質的には下記の２つのコードを合体したものになります。
+① original.gs
+・認証・認可の処理を行う専用のファイル。
+・アクセストークンを保管するとともに、②からの要求に応じて authorizationUrl やアクセストークンを渡す。
+```js
+AUTH_ENDPOINT = 'https://XXX';
+TOKEN_ENDPOINT = 'https://YYY';
+CLIENT_ID = 'AAA';
+CLIENT_SECRET = 'BBB';
+APP_ID = 'CCC';
+// OAuth2ライブラリ使用
+function getService() {
+　略
+}
+function authCallback(request) {
+　略
+}
+function doGet(e) {
+  if (e.parameter.authmode)
+    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })
+  if (getService.hasAccess())
+    return toJson({ authorized: true, token: getService.getAccessToken() })
+  return toJson({ authorized: false })
+}
+function toJson(content) {
+　略
+}
+```
+② copy.gs
+・実際の処理を行うファイル
+```js
+const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL
+/**
+ * 認証用ダイアログ（html）表示
+ * セラーセントラルの認証URLへリンクさせる
+ */
+function showDialog() {
+  const respjson = UrlFetchApp.fetch(DEPLOY_URL + '?authmode=true').getContentText();
+  const response = JSON.parse(respjson);
+  const url = response.authorizationUrl;
+  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
+  const html = HtmlService.createHtmlOutput(tag_text);
+  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
+}
+/**
+ * アクセストークンを取得する。
+ */
+function getToken() {
+  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
+  const response = JSON.parse(respjson);
+  if (response.authorized) {
+    return response.token;
+  } else {
+    return "UNAUTHORIZED"
+  }
+}
+/*個別処理を行う場合に必要となるアクセストークンは、getToken() で取得する。
+ * 下記は注文を取得する例。
+*/
+function getOrders(){
+  const access_token = getToken(); // アクセストークンの取得
+  if (access_token==='UNAUTHORIZED) {
+    console.log('認証が完了していないためアクセストークンを取得できません。' +
+      管理者に連絡して、認証・認可ファイルで再認証を行ってもらってください。');
+  }
+  略
+  const end_point = 'https://sellingpartnerapi-eu.amazon.com';
+　略
+  const options = {
+    'method': 'GET',
+    'headers': {
+      'x-amz-access-token': access_token,
+      'x-amz-date': isoDate,
+      'Authorization': 'AWS4-HMAC-SHA256 Credential=' + ACCESS_ID + '/' + credential_scope + ', SignedHeaders=' + signedheaders + ', Signature=' + signature,
+    }
+  }
+  const orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
+  console.log(orders);
+}
+```
+上記のように２つに分けた場合は、①単独では動かず、②の copy.js を複製して使用することを想定しています。
+（冒頭に記載したコードは、①と②を合体したものですので、単一のファイルだけで動くはずです）
+②で認証・認可が必要になる場面で ①を呼び出して認証・認可に必要な処理を肩代わりさせます。
+この過程でアクセストークンを ①の中に保管しておきます。
+実際に②がいろいろな処理を行う場面でアクセストークンが必要になった場合は、getToken()によって①からアクセストークンを取得する、という考え方です。
+-----
+# 追記
+他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
+・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
+これは、①と②両方公開ファイルにしても変わりません。
++ ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
++ ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
+したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
+運用方針として、①と②を分離し、
++ ①は開発者／管理者が専有してメンテナンス（最初だけ認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
++ 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
+というのが現実的かもしれませんね。
+crient_secret が書かれたファイルをむやみに渡す必要がなくなるというメリットもあると思います。
+ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
+（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも明記されてしまっているのが問題）
+①改（認証・認可用ファイル。showDialogを元に戻した）
+```js
+AUTH_ENDPOINT = 'https://XXX';
+TOKEN_ENDPOINT = 'https://YYY';
+CLIENT_ID = 'AAA';
+CLIENT_SECRET = 'BBB';
+APP_ID = 'CCC';
+// OAuth2ライブラリ使用
+function getService() {
+　略
+    .setLock(LockService.getUserLock());
+}
+function authCallback(request) {
+　略
+}
+function doGet(e) {
+  if (e.parameter.authmode)
+    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })
+  if (getService.hasAccess())
+    return toJson({ authorized: true, token: getService.getAccessToken() })
+  return toJson({ authorized: false })
+}
+function toJson(content) {
+　略
+}
+/**
+ * 認証用ダイアログ（html）表示
+ * セラーセントラルの認証URLへリンクさせる
+ */
+function showDialog(){
+  const service = getService();
+  const url = service.getAuthorizationUrl();
+  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
+  const html = HtmlService.createHtmlOutput(tag_text);
+  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
+}
+```
+②改’（実際の処理を行うファイル。こちらを複製。showDialogは①へ移動）
+```js
+const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL
+/**
+ * アクセストークンを取得する。
+ */
+function getToken() {
+  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
+  const response = JSON.parse(respjson);
+  if (response.authorized) {
+    return response.token;
+  } else {
+    return "UNAUTHORIZED"
+  }
+}
+/*個別処理を行う場合に必要となるアクセストークンは、getToken() で取得する。
+ * 下記は注文を取得する例。
+*/
+function getOrders(){
+  const access_token = getToken(); // アクセストークンの取得
+  if (access_token==='UNAUTHORIZED) {
+    console.log('認証が完了していないためアクセストークンを取得できません。' +
+      管理者に連絡して、認証・認可ファイルで再認証を行ってもらってください。');
+  }
+  略
+  const end_point = 'https://sellingpartnerapi-eu.amazon.com';
+　略
+  const options = {
+    'method': 'GET',
+    'headers': {
+      'x-amz-access-token': access_token,
+      'x-amz-date': isoDate,
+      'Authorization': 'AWS4-HMAC-SHA256 Credential=' + ACCESS_ID + '/' + credential_scope + ', SignedHeaders=' + signedheaders + ', Signature=' + signature,
+    }
+  }
+  const orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
+  console.log(orders);
+}
+```

2022/05/01 01:20

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -180,9 +180,9 @@
 したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
-運用方針として、①と②を分離してしまい、
+運用方針として、①と②を分離し、
-+ ①は開発者／管理者が専有してメンテナンス（最初に認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
++ ①は開発者／管理者が専有してメンテナンス（最初だけ認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
-+ 利用者側には②コピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
++ 利用者側には②をコピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
 というのが現実的かもしれませんね。
 crient_secret が書かれたファイルをむやみに渡す必要がなくなるというメリットもあると思います。

2022/04/30 23:41

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -185,7 +185,7 @@
 + 利用者側には②コピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
 というのが現実的かもしれませんね。
-crient_secret をむやみに公開する必要がなくなるというメリットもあると思います。
+crient_secret が書かれたファイルをむやみに渡す必要がなくなるというメリットもあると思います。
 ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
 （この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも明記されてしまっているのが問題）

2022/04/30 23:38

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -201,6 +201,7 @@
 // OAuth2ライブラリ使用
 function getService() {
 　略
+    .setLock(LockService.getUserLock());
 }
 function authCallback(request) {

2022/04/30 23:36

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -188,7 +188,7 @@
 crient_secret をむやみに公開する必要がなくなるというメリットもあると思います。
 ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
-（この点は冒頭に記載した単一ファイルを運用する場合でも同じです）
+（この点は冒頭に記載した単一ファイルを運用する場合でも同じです。さらに単一ファイルだとclient_secretも明記されてしまっているのが問題）
 ①改（認証・認可用ファイル。showDialogを元に戻した）
 ```js

2022/04/30 23:35

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -187,7 +187,7 @@
 crient_secret をむやみに公開する必要がなくなるというメリットもあると思います。
-ただし、DEPLOY_URLを知られてしまうと勝手にいろいろできてしまうので、ユーザー管理のしくみは別途必要かもしれません。
+ただし、現状のコードだと、DEPLOY_URLを知られてしまうだけでアクセストークンを取得して勝手にいろいろできてしまうので、何らかの管理のしくみが別途必要かもしれません。
 （この点は冒頭に記載した単一ファイルを運用する場合でも同じです）
 ①改（認証・認可用ファイル。showDialogを元に戻した）

2022/04/30 23:33

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -177,15 +177,16 @@
 これは、①と②両方公開ファイルにしても変わりません。
 + ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
 + ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
-したがって、
-少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
+したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
-①と②の運用を完全に分離し、
+運用方針として、①と②を分離してしまい、
-+ ①は開発者側が専有してメンテナンス（最初に認証を行ってリフレッシュトークン・アクセストークンをキャッシュ）
++ ①は開発者／管理者が専有してメンテナンス（最初に認証を行ってリフレッシュトークン・アクセストークンをキャッシュしておく）
 + 利用者側には②コピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
-、というのが現実的かもしれませんね。
+というのが現実的かもしれませんね。
 crient_secret をむやみに公開する必要がなくなるというメリットもあると思います。
 ただし、DEPLOY_URLを知られてしまうと勝手にいろいろできてしまうので、ユーザー管理のしくみは別途必要かもしれません。
 （この点は冒頭に記載した単一ファイルを運用する場合でも同じです）

2022/04/30 23:31

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -175,14 +175,20 @@
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
 ・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
 これは、①と②両方公開ファイルにしても変わりません。
-・①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
++ ①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
-・①を所有しているアカウント以外のアカウントが ②を利用中にアクセストークンを更新できるか
++ ①の発行しているアクセストークンが揮発しても、①を所有しているアカウント以外のアカウントは ②を利用中に更新後のアクセストークンを取得できる。
-~~についてはまだ確認できていません。~~ →更新できているようです。
 したがって、
 少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
+①と②の運用を完全に分離し、
-①と②の運用を完全に分離し、①は開発者側が専有してメンテナンス（最初に認証を行ってリフレッシュトークン・アクセストークンをキャッシュ）、利用者側には②を使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）、というのが現実的かもしれませんね。
++ ①は開発者側が専有してメンテナンス（最初に認証を行ってリフレッシュトークン・アクセストークンをキャッシュ）
++ 利用者側には②コピーして使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）
+、というのが現実的かもしれませんね。
+crient_secret をむやみに公開する必要がなくなるというメリットもあると思います。
+ただし、DEPLOY_URLを知られてしまうと勝手にいろいろできてしまうので、ユーザー管理のしくみは別途必要かもしれません。
+（この点は冒頭に記載した単一ファイルを運用する場合でも同じです）
 ①改（認証・認可用ファイル。showDialogを元に戻した）
 ```js
 AUTH_ENDPOINT = 'https://XXX';

2022/04/30 23:26

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -266,7 +266,7 @@
       'Authorization': 'AWS4-HMAC-SHA256 Credential=' + ACCESS_ID + '/' + credential_scope + ', SignedHeaders=' + signedheaders + ', Signature=' + signature,
     }
   }
-  consr orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
+  const orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
   console.log(orders);
 }
 ```

2022/04/30 23:25

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -250,6 +250,10 @@
 */
 function getOrders(){
   const access_token = getToken(); // アクセストークンの取得
+  if (access_token==='UNAUTHORIZED) {
+    console.log('認証が完了していないためアクセストークンを取得できません。' +
+      管理者に連絡して、認証・認可ファイルで再認証を行ってもらってください。');
+  }
   略
   const end_point = 'https://sellingpartnerapi-eu.amazon.com';

2022/04/30 23:22

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -182,3 +182,88 @@
 したがって、
 少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
 ①と②の運用を完全に分離し、①は開発者側が専有してメンテナンス（最初に認証を行ってリフレッシュトークン・アクセストークンをキャッシュ）、利用者側には②を使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）、というのが現実的かもしれませんね。
+①改（認証・認可用ファイル。showDialogを元に戻した）
+```js
+AUTH_ENDPOINT = 'https://XXX';
+TOKEN_ENDPOINT = 'https://YYY';
+CLIENT_ID = 'AAA';
+CLIENT_SECRET = 'BBB';
+APP_ID = 'CCC';
+// OAuth2ライブラリ使用
+function getService() {
+　略
+}
+function authCallback(request) {
+　略
+}
+function doGet(e) {
+  if (e.parameter.authmode)
+    return toJson({ authorizationUrl: getService.getAuthorizationUrl() })
+  if (getService.hasAccess())
+    return toJson({ authorized: true, token: getService.getAccessToken() })
+  return toJson({ authorized: false })
+}
+function toJson(content) {
+　略
+}
+/**
+ * 認証用ダイアログ（html）表示
+ * セラーセントラルの認証URLへリンクさせる
+ */
+function showDialog(){
+  const service = getService();
+  const url = service.getAuthorizationUrl();
+  const tag_text = `<button type="button" class="btn btn-primary" onclick="window.open('${url}')">セラーセントラルで認証する</button>`;
+  const html = HtmlService.createHtmlOutput(tag_text);
+  SpreadsheetApp.getUi().showModalDialog(html, "認証ダイアログ");
+}
+```
+②改’（実際の処理を行うファイル。こちらを複製。showDialogは①へ移動）
+```js
+const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL
+/**
+ * アクセストークンを取得する。
+ */
+function getToken() {
+  const respjson = UrlFetchApp.fetch(DEPLOY_URL).getContentText();
+  const response = JSON.parse(respjson);
+  if (response.authorized) {
+    return response.token;
+  } else {
+    return "UNAUTHORIZED"
+  }
+}
+/*個別処理を行う場合に必要となるアクセストークンは、getToken() で取得する。
+ * 下記は注文を取得する例。
+*/
+function getOrders(){
+  const access_token = getToken(); // アクセストークンの取得
+  略
+  const end_point = 'https://sellingpartnerapi-eu.amazon.com';
+　略
+  const options = {
+    'method': 'GET',
+    'headers': {
+      'x-amz-access-token': access_token,
+      'x-amz-date': isoDate,
+      'Authorization': 'AWS4-HMAC-SHA256 Credential=' + ACCESS_ID + '/' + credential_scope + ', SignedHeaders=' + signedheaders + ', Signature=' + signature,
+    }
+  }
+  consr orders = UrlFetchApp.fetch(end_point + canonicalURI + canonicalQueryString, options);
+  console.log(orders);
+}
+```

2022/04/30 22:33

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -181,4 +181,4 @@
 したがって、
 少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
-①と②の運用を完全に分離し、①は開発者側が専有してメンテナンス、利用者側に②を使ってもらう、というのが現実的かもしれまsね。
+①と②の運用を完全に分離し、①は開発者側が専有してメンテナンス（最初に認証を行ってリフレッシュトークン・アクセストークンをキャッシュ）、利用者側には②を使ってもらう（①がアクセストークンを保持している限り②側での認証フローは不要）、というのが現実的かもしれませんね。

2022/04/30 14:59

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -176,6 +176,9 @@
 ・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
 これは、①と②両方公開ファイルにしても変わりません。
 ・①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
-・①を所有しているアカウント以外のアカウントが ②を利用中にアクセストークンを更新できるかについてはまだ確認できていません。
+・①を所有しているアカウント以外のアカウントが ②を利用中にアクセストークンを更新できるか
+~~についてはまだ確認できていません。~~ →更新できているようです。
+したがって、
-したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
+少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。
+①と②の運用を完全に分離し、①は開発者側が専有してメンテナンス、利用者側に②を使ってもらう、というのが現実的かもしれまsね。

2022/04/30 12:05

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -174,6 +174,7 @@
 他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
 ・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
+これは、①と②両方公開ファイルにしても変わりません。
 ・①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
 ・①を所有しているアカウント以外のアカウントが ②を利用中にアクセストークンを更新できるかについてはまだ確認できていません。

追記

2022/04/30 12:04

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -169,3 +169,12 @@
 実際に②がいろいろな処理を行う場面でアクセストークンが必要になった場合は、getToken()によって①からアクセストークンを取得する、という考え方です。
+-----
+# 追記
+他の人にも協力してもらい、いろいろ試しましたが、このスクリプトは下記のような根本的な問題点があるらしいことが分かりました。
+・①を所有しているアカウント以外のアカウントが ②の showDialog を実行した場合、認証フローを完了させることができない（トークンが無効または期限が切れていると表示される）
+・①での認証後、①を所有しているアカウント以外のアカウントが ②を利用して①からアクセストークンを受け取り、アクセストークンを利用した処理を行うことは一応可能。
+・①を所有しているアカウント以外のアカウントが ②を利用中にアクセストークンを更新できるかについてはまだ確認できていません。
+したがって、少なくとも最初の認証フローは①を所有しているアカウント（①を作成したアカウント）で行う必要がありそうです。

2022/04/30 11:51

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -8,7 +8,11 @@
 + セラーセントラルのAPI登録画面でのリダイレクトURIは、コピー元のcallbackから変更する必要はありません。
++ 複数ユーザーの同時アクセスに対応するためgetService関数の中でロックを設定しています。（ [参照](https://github.com/googleworkspace/apps-script-oauth2#locking) )
+※実際にはその他の処理でも複数ユーザーによる競合が想定される部分には、ロックをかける必要があるかもしれません。
  DEPLOY_URLを追加しているほか、showDialog() も一部修正しています。
 ```js
 AUTH_ENDPOINT = 'https://XXX';
 他...
@@ -20,6 +24,7 @@
 // OAuth2ライブラリ使用
 function getService() {
 　略
+    .setLock(LockService.getUserLock());  // 複数ユーザーが同時にトークンをリフレッシュしようとする可能性があるためロックを設定。
 }
 /**

2022/04/30 11:20

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -59,14 +59,14 @@
 }
 /**
- * GETリクエスト時に呼ばれる。
+ * クライアントからGETリクエストを受けた時に呼ばれる。
  * @return : JSON string
  *  呼び出し元に「authmode」パラメータが存在する場合
  *  　{"authorizationUrl : 認可URL}
  *  呼び出し元に「authmode」パラメータが存在せず、認可済みの場合
  * 　 {"anthorized" : true, "token" : アクセストークン}
  *  呼び出し元に「authmode」パラメータが存在せず、未認可の場合
- *   {"authorized" : "false"}
+ *   {"authorized" : false}
  */
 function doGet(e) {
   if (e.parameter.authmode)

2022/04/30 10:48

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -92,7 +92,7 @@
 上記は、実質的には下記の２つのコードを合体したものになります。
 ① original.gs
 ・認証・認可の処理を行う専用のファイル。
-・アクセストークンを保管するとともに、②からの要求に応じてトークンを渡す。
+・アクセストークンを保管するとともに、②からの要求に応じて authorizationUrl やアクセストークンを渡す。
 ```js
 AUTH_ENDPOINT = 'https://XXX';
 TOKEN_ENDPOINT = 'https://YYY';

2022/04/30 10:47

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -91,6 +91,8 @@
 上記は、実質的には下記の２つのコードを合体したものになります。
 ① original.gs
+・認証・認可の処理を行う専用のファイル。
+・アクセストークンを保管するとともに、②からの要求に応じてトークンを渡す。
 ```js
 AUTH_ENDPOINT = 'https://XXX';
 TOKEN_ENDPOINT = 'https://YYY';
@@ -123,6 +125,7 @@
 ```
 ② copy.gs
+・実際の処理を行うファイル
 ```js
 const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL

2022/04/30 10:44

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -157,7 +157,6 @@
 （冒頭に記載したコードは、①と②を合体したものですので、単一のファイルだけで動くはずです）
 ②で認証・認可が必要になる場面で ①を呼び出して認証・認可に必要な処理を肩代わりさせます。
-（ たとえば、showDialog関数内で取得している authorizationUrl のリダイレクト先は①になっています）
 この過程でアクセストークンを ①の中に保管しておきます。
 実際に②がいろいろな処理を行う場面でアクセストークンが必要になった場合は、getToken()によって①からアクセストークンを取得する、という考え方です。

2022/04/30 10:43

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -157,6 +157,7 @@
 （冒頭に記載したコードは、①と②を合体したものですので、単一のファイルだけで動くはずです）
 ②で認証・認可が必要になる場面で ①を呼び出して認証・認可に必要な処理を肩代わりさせます。
+（ たとえば、showDialog関数内で取得している authorizationUrl のリダイレクト先は①になっています）
 この過程でアクセストークンを ①の中に保管しておきます。
 実際に②がいろいろな処理を行う場面でアクセストークンが必要になった場合は、getToken()によって①からアクセストークンを取得する、という考え方です。

2022/04/30 10:41

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -156,7 +156,7 @@
 上記のように２つに分けた場合は、①単独では動かず、②の copy.js を複製して使用することを想定しています。
 （冒頭に記載したコードは、①と②を合体したものですので、単一のファイルだけで動くはずです）
-②で認証が必要になる場面で ①を呼び出して認証処理を肩代わりさせます。
+②で認証・認可が必要になる場面で ①を呼び出して認証・認可に必要な処理を肩代わりさせます。
 この過程でアクセストークンを ①の中に保管しておきます。
 実際に②がいろいろな処理を行う場面でアクセストークンが必要になった場合は、getToken()によって①からアクセストークンを取得する、という考え方です。

2022/04/30 10:38

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -124,7 +124,7 @@
 ② copy.gs
 ```js
-const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // コピー元のデプロイURL
+const DEPLOY_URL = 'https://script.google.com/macros/s/***/exec';  // ①のデプロイURL
 /**
  * 認証用ダイアログ（html）表示

2022/04/30 10:30

投稿

退会済みユーザー

スコア0

test CHANGED Viewed

@@ -4,7 +4,7 @@
 + 逆に、コピー元のデプロイURLが変わってしまった場合は、コピー先ファイルに記載されているDEPLOY_URLを全部そのURLに修正しなければなりません。
-+ アクセストークンを使うときは、その都度、getToken() を呼び出してください。
++ **アクセストークンを使うときは、その都度、getToken() を呼び出してください**。
 + セラーセントラルのAPI登録画面でのリダイレクトURIは、コピー元のcallbackから変更する必要はありません。
@@ -89,7 +89,7 @@
 -----
 # 説明
-上記は、実質的に下記の２つのコードを合算したものになります。
+上記は、実質的には下記の２つのコードを合体したものになります。
 ① original.gs
 ```js
 AUTH_ENDPOINT = 'https://XXX';
@@ -154,7 +154,7 @@
 ```
 上記のように２つに分けた場合は、①単独では動かず、②の copy.js を複製して使用することを想定しています。
-（最初のコードの場合は、①と②を合体しているので、単一のファイルだけで動くはずです）
+（冒頭に記載したコードは、①と②を合体したものですので、単一のファイルだけで動くはずです）
 ②で認証が必要になる場面で ①を呼び出して認証処理を肩代わりさせます。
 この過程でアクセストークンを ①の中に保管しておきます。