バッチ処理＆API利用にあたっての、各種資格情報の扱いについて
バッチ処理＆API利用にあたっての、各種資格情報の扱いについて
お世話になります。
APIに限ったことではないのかもしれませんが……。
ECサイトの在庫管理・連携にNE：ネクストエンジンを既に利用していて、
自社商品マスターや在庫などの操作のためにバッチ処理の作成を検討しています。
想像図としては以下のとおりです。
[ NEサーバ ]
↑↓ API経由で商品情報の取得・変更、在庫の変更
[ 自社Webサーバ ]
↑↓ 在庫数の確認や注文前の確認等
[ 末端顧客 ]
また現状では以下の通りと理解しています。
・「アプリ」は特定のネクストエンジンID（が使用する商品等データベース）と直接紐付くものではない
・client_id & client_secret は「アプリ」を識別するためのもの
・（提供SDKがphp/javaのみであったことから） javascriptなどにより利用者が直接APIを叩くことは想定されていない
・uid, stateは、以下の流れでNEサーバから利用者を経てアプリに授受される
1．利用者ブラウザからネクストエンジンへログインを行う
2．利用者ブラウザに https://base.next-engine.org/ 以下のcookieとして資格情報がセットされる
3．利用者ブラウザが https://base.next-engine.org/users/sign_in/ に client_id, secret をもってアクセスする（アクセス時にcookie送信）
4．レスポンス内容中の<a>およびHTTPレスポンスヘッダのリダイレクト先URLに、uid, state が追加される
5．リダイレクト先のURL ≒ アプリが uid, state を受け取る
質問は以下の通りです。
○ バッチ処理が目的であれば、実際に外部からredirect_urlにアクセスできる必要はなく、
また、これのためだけに、HTTPS接続できるWebサーバを用意する必要もない、と考えて良いか？
○ バッチ処理を念頭に置いた場合、uid/stateやaccess_token/refresh_tokenが失効した際に
毎回手動でネクストエンジンへの「ログイン」を行わねばならないとなると
完全に自動化とならず不便であるため、「ネクストエンジンへのログイン」自体も自動化したいと考えているが
マニュアルにはこのあたりについての記述を見出せず、
SDKの中身を見るとNEログイン処理はあくまで画面ベース（ブラウザベース）で行うかたちである模様であった。
プログラムによる「ネクストエンジンへのログイン」の自動化は可か、不可か？
可である場合、やり方など制限や規則はあるか？
また、現在のログインの仕組みは将来変更が予定されているか？
○ 上記NEへの自動ログインが不可であった場合特に問題となるが、
access_token/refresh_token（旧）両方を使用してのAPIアクセス時、
新規access_token/refresh_token（新）が発行される際に、（旧）の各tokenは失効するか？
また、上記および有効期間経過による失効以外に、失効することはありうるか？
※要するに、自動ログインできない場合、1日数回のAPI利用を確実に行っていれば
間違いなく永続的にtokenを使用し続けられるのか、ということです
マニュアル「refresh_tokenについて」に、マルチスレッド絡みで注意事項の記述があったため、もしや、と
ご回答よろしくお願い致します。
RE:バッチ処理＆API利用にあたっての、各種資格情報の扱いについて
回答いたします。
>バッチ処理が目的であれば、実際に外部からredirect_urlにアクセスできる必要はなく、
>また、これのためだけに、HTTPS接続できるWebサーバを用意する必要もない、と考えて良いか？
→バッチ処理自体はredirect_urlにアクセス必要ありませんが、最初の認証のためにuid/stateでaccess_token/refresh_tokenを取得する必要があるため、 HTTPS接続できるWebサーバを用意する必要があります。
バッチ処理を念頭に置いた場合、uid/stateやaccess_token/refresh_tokenが失効した際に
毎回手動でネクストエンジンへの「ログイン」を行わねばならないとなると
完全に自動化とならず不便であるため、「ネクストエンジンへのログイン」自体も自動化したいと考えているが
マニュアルにはこのあたりについての記述を見出せず、
SDKの中身を見るとNEログイン処理はあくまで画面ベース（ブラウザベース）で行うかたちである模様であった。
>プログラムによる「ネクストエンジンへのログイン」の自動化は可か、不可か？
>可である場合、やり方など制限や規則はあるか？
→前述の通り、最初の認証のために必ずWebアプリ(ブラウザベース)をご用意していただく必要があります。
最初にWebアプリでaccess_token/refresh_tokenを取得後、DB等に保持しaccess_token/refresh_tokenを最新の状態にするような仕組みを構築することで、その後は更新された最新のaccess_token/refresh_tokenを利用することにより自動化することが可能です。
また、ご参考までにfuelPHPになりますが access_token/refresh_tokenを更新する仕組みがある、「ネクストエンジンアプリ基盤」を提供しております。
https://developer.next-engine.com/tutorial/sample-fuelphp
>また、現在のログインの仕組みは将来変更が予定されているか？
→現時点では変更の予定はありませんが、将来的に変更を検討する可能性はあります。
>上記NEへの自動ログインが不可であった場合特に問題となるが、
>access_token/refresh_token（旧）両方を使用してのAPIアクセス時、
>新規access_token/refresh_token（新）が発行される際に、（旧）の各tokenは失効するか？
>また、上記および有効期間経過による失効以外に、失効することはありうるか？
>※要するに、自動ログインできない場合、1日数回のAPI利用を確実に行っていれば
>間違いなく永続的にtokenを使用し続けられるのか、ということです
>マニュアル「refresh_tokenについて」に、マルチスレッド絡みで注意事項の記述があったため、もしや、と
→新しいaccess_token/refresh_tokenが発行されると旧のtokenは失効します。
1日数回のAPI利用で最後に利用したaccess_token/refresh_tokenを利用する事によって使用し続けられます。
前述の補足になりますが、API利用後にレスポンスされたaccess_token/refresh_tokenをDB等に保持するような仕組みを構築すれば、永続的にaccess_token/refresh_tokenを利用する事が可能です。
ご回答ありがとうございます。
ご回答ありがとうございます。
追加で 4点、質問させて頂きたく、以下申し上げます。
※追加の質問 4点につき、質問部分に ● を付させて頂いております
----- ----- -----
> >バッチ処理が目的であれば、実際に外部からredirect_urlにアクセスできる必要はなく、
> >また、これのためだけに、HTTPS接続できるWebサーバを用意する必要もない、と考えて良いか？
>
> → バッチ処理自体はredirect_urlにアクセス必要ありませんが、(...) HTTPS接続できるWebサーバを用意する必要があります。
わたくしの記述が曖昧であり申し訳ありません。
●「サーバ証明書を導入し、HTTPS接続要求を受け入れられる、Webサーバ」を用意する必要の有無はいかがでしょうか？
※「base.next-engine.orgに対してHTTPS接続を投げられる」サーバ、ではなく
※「https://domain-name/path/」というURLを提供できるサーバ、という意味合いです
----- ----- -----
> >プログラムによる「ネクストエンジンへのログイン」の自動化は可か、不可か？
> >可である場合、やり方など制限や規則はあるか？
>
> →前述の通り、最初の認証のために必ずWebアプリ(ブラウザベース)をご用意していただく必要があります。
●「プログラムによる「ネクストエンジンへのログイン」の自動化」の許可は頂けない、実施してはいけない、という認識で相違ないでしょうか？
----- ----- -----
> >また、現在のログインの仕組みは将来変更が予定されているか？
> →現時点では変更の予定はありませんが、将来的に変更を検討する可能性はあります。
●前項の質問に対するご回答が否であった場合のみですが、変更される/された際に、告知・アナウンス等は行って頂けるのでしょうか？
----- ----- -----
> →新しいaccess_token/refresh_tokenが発行されると旧のtokenは失効します。
> 1日数回のAPI利用で最後に利用したaccess_token/refresh_tokenを利用する事によって使用し続けられます。
新規tokenが発行されると同時に、即座に旧tokenが失効するということですね。
そしてつまり、実装次第とはいえ、例えば
[ 1時間に自動的に1回実行する予定のバッチが、不測のトラブル等により、1時間以上継続的に実行された ]
などの場合に、実装したtokenの保存/読み取り 各処理のタイミングによっては、
24時間ないし72時間以内の再アクセスであっても、認証に失敗する可能性がある、ということですね。
1．「24時間ないし72時間の有効期限経過」
2．「新token発行による失効」
●上記 2点以外に、tokenが失効する可能性はあるか、ないか、につきましてはいかがでしょうか？
また、ある場合、どのような理由・原因によるものでしょうか？
----- ----- -----
RE:RE:バッチ処理＆API利用にあたっての、各種資格情報の扱いについて
※「返信」に切り替えるためコメント削除
RE:ご回答ありがとうございます。
ご質問ありがとうございます。
追加質問について確認いたしますので、回答までしばらくお待ちいただきますようお願い致します。
RE:ご回答ありがとうございます。
回答ですが、バッチプログラムによるAPIの利用の流れについて以下QAで纏めておりますので、こちらをご確認いただき再度不明点等ありましたら、ご質問いただければと思います。
https://developer.next-engine.com/node/47
上記のページの項番1で 「少なくとも初回は必ず1）の対応が必要なため、・・・」とあり、1）の方法でアクセストークンとリフレッシュトークンを取得 するためには「サーバ証明書を導入し、HTTPS接続要求を受け入れられる、Webサーバ」を用意する必要があります。
サーバー証明書は必ずしも有償である必要はなく、最初のアクセストークンを取得するだけれあればローカル環境で取得する方法があります。詳しくはこちらをご覧ください。
https://developer.next-engine.com/questions/19
バッチプログラムだけでの自動認証は不可となっております。(初回を上記手順で手動でトークンを取得できれば、その後はプログラムによって最新のトークンを保持することにより可能)
>●上記 2点以外に、tokenが失効する可能性はあるか、ないか、につきましてはいかがでしょうか？
> また、ある場合、どのような理由・原因によるものでしょうか？
その他にはapiのリクエストがエラーになった時も更新されます。
詳しくは以下、補足説明をご覧ください。
https://developer.next-engine.com/api/refresh_token
>●前項の質問に対するご回答が否であった場合のみですが、変更される/された際に、告知・アナウンス等は行って頂けるのでしょうか？
API等の仕組みが変更された場合はTOPページの更新履歴でアナウンスしております。
https://developer.next-engine.com/