nononosuque
投稿
コメント
状況理解しました。 サイト「https://jwt.io/」を利用したことがないので出来るとは言えないのですが、 何らかRPAツールをご利用されているようであれば、 「https://jwt.io/」を利用したJWTの生成をRPAに実施させることで、処理化することは可能かもしれません。
API 全般 2022.12.19
>前提としては日時指定が必要となるのですが、 >頂いた回答を見ると日時指定でも制約なく取得できるように見えますがあっていますでしょうか? From指定の制限日については、ドキュメント上に記載がない認識です。 なのでおそらくの回答とはなりますが、 登録日、更新日とマッチする範囲であれば、指定する日付に制限はないのではと推測します。 もし不安な場合は、 日時指定なしで全件取得することで取得結果の合計が管理画面上の登録数とは一致するはずです。
その他 2022.12.19
厳密には違うかと思いますが、 Rate Limitsの適用対象にプランごとのScopeのRate Limitsが記載されています。 https://developers.worksmobile.com/jp/reference/rate-limits?lang=ja プランごとのRate Limits=そのプランで利用可能なScopeの参考になるのかなと思います。 但し、スタンダードプランなんかはオプション商品(https://line.worksmobile.com/jp/pricing/)を追加することで利用可能になるAPI Scopeも↑の表には記載されているように見えます(group.folderとかuser.email.readとか)ので、 そのあたりは注意が必要かもです。 あくまで参考程度です。
API 全般 2022.12.16
>ちなみに、「JWTファイル生成」も「処理可」することができているのでしょうか?それとも私のように、手作業でしょうか? ⇒私も「JWTファイル生成」と記載してしまったのですが、 LWのドキュメントに記載の「JWTの生成」の意味合いの理解であっておりますでしょうか。 https://developers.worksmobile.com/jp/reference/authorization-sa?lang=ja その前提であれば、「JWTの生成」は処理化(プログラムの処理に組み込むこと)することは可能な認識です。 私の場合は、 JWT生成からアクセストークン取得+利用APIの実行までワンクリックで実行できるようにしています。 WindowsのタスクスケジューラーやRPA等にexeの実行を組み込むことはやっていませんが、 エラー時のチェック/通知/再実行の問題もあるかと思いますが、組み込むことで自動化させることも可能だと思います。
>こちらは過去何日前まで指定可能かご教授頂けますでしょうか? ⇒明確に何日登録分から取得するような要件があるのではなく、全件が取得できれば良い認識であっていますか? 以下はその前提での回答になります。 >制約があって、過去データの取得ができないケースを懸念しています。 極端な例ですが、以下のHTTP RequestですとQuery Parametersは、[orderBy]しか選択していませんが、取得可能です。 https://www.worksapis.com/v1.0/contacts?orderBy=createdTime ↑のHTTP RequestとcursorのQuery Parametersを上手くつなげていくことで、 5万件であれば取得可能な認識です。 仮に5万件以上登録されている場合でも、10万件以内であれば、 orderBy=createdTimeの昇順と降順でそれぞれAPI発行することで、一部被りの取得はあるかもですが、 すべてのデータを網羅できるかと思います。 開始/終了日時フィルターのQuery Parametersは、必須ではないです。 前提が違っていたらすみません。
その他 2022.12.16
>最長で90日に一度は、「JWTファイル生成しなおして、AccessTokenを取得する」ということをみなさん実施されているのでしょうか? あまり参考にならないかもです。 私の場合、リフレッシュトークンは利用していないです。 毎回アクセストークン取得しています(=都度JWTファイル生成とアクセストークン取得を行っています。) フローにリフレッシュトークンの利用を組み込む場合、 アクセストークン取得までのパターンが以下の2つに分かれます。 ①JWTファイル生成してアクセストークン取得 ②リフレッシュトークンを利用してアクセストークン取得 2パターンある=発行までのフローに条件付けて組み込む必要があるので、 逆に制御などが面倒かもということで、 アクセストークン取得にあたり、発行までのフローで条件付けが不要な①で回しています。
グループ会社機能を使っているユーザー向けの記載 (各ドメインのアプリ情報なのか、例えば代表のアプリ情報で良いのか)がないですよね・・・。 各APIの仕様ページ上に221216時点では記載がないと私も認識していますが、 ここに記載があるよとご存じの方がいれば是非ご指摘頂きたいです。 網羅できていないので、あまり参考にはならないかと思いますが、 個人的に確認したものについて、共有させて頂きます。 ユーザーAPIの中でも以下については、所属するドメインのアプリ情報を利用する必要がありそうです。 ※22.9.20時点の確認なので、変わっている可能性もありますが・・・。 ■ユーザーに外部 LINE ユーザーとのトーク権限付与 https://developers.worksmobile.com/jp/reference/user-link-to-line-create?lang=ja と ■ユーザーの外部 LINE ユーザーとのトーク権限解除 https://developers.worksmobile.com/jp/reference/user-link-to-line-delete?lang=ja は実際に適用しようとしているアカウントが所属しているドメインのアプリ情報が必要なことを確認しています。 以下で起票させていただいた通り、 この時は、実際に適用しようとしているアカウントの所属するドメインのアプリ情報を利用しない (代表などの別ドメインのアプリ情報を利用)でAPI発行するとドキュメントに記載のない httpsステータスコード:202が返却されます。 https://forum.worksmobile.com/jp/posts/101158 推測ですが、 ユーザーに外部 LINE WORKS ユーザーとのトーク権限付与と解除及び、 すべてのユーザーに外部LINE/外部LINEWORKSユーザーとのトーク権限付与あたりも 同じく所属しているドメインのアプリ情報が必要ぽいと思っています。 他にもあるかもしれません。 逆に 以下については、更新対象が所属していないドメインのアプリ情報(どのドメインのアプリ情報)でも発行できることを確認しています。 ※こちらも個人的に確認(22/12/01あたり時点)したもので公式で発信されているわけではないです。 User ・ユーザーの取得 ・ユーザーの部分更新 ・ユーザーの削除 ・ユーザーの削除取消 Group ・グループリストの取得 ・グループの取得 ・グループの部分更新 ・グループの削除 ・チーム/グループ - ファイルリストの取得 ・チーム/グループ - ルートフォルダのファイルリストの取得 ・チーム/グループ - ファイルの削除 ・チーム/グループ - ファイル名の変更 ・チーム/グループ - ファイルのロック設定 ・チーム/グループ - ファイルのロック解除 Calendar ・基本カレンダーの予定の取得 ・基本カレンダーの予定の登録 ・基本カレンダーの予定の更新
2022.12.16
実際に試してはいませんが、 APIのドキュメントを参照する限り、ユーザーの部分更新のAPIを利用することで、External keyをAPIで設定することは可能だと思います。 https://developers.worksmobile.com/jp/reference/user-update-patch?lang=ja またAPIではなく、 LINEWORKSのDeveloper Consoleの画面から、CSVによるLINEWORKSドメイン単位のユーザーに対するExternal keyの一括設定(アップロード)が可能かと思います。
SSO 2022.11.25
LINE WORKS担当者様 ご確認頂き大変ありがとうございました。 >本事象については今後のバージョンにて修正を予定しております。 →承知致しました。 修正されたタイミングを拾えるように今後のバージョンの更新内容を確認致します。 グループの棚卸等にグループAPIを活用しており、 首を長くして修正をお待ちしております。
API 全般 2022.11.18
saito makotoさん ありがとうございます! 利用しているAPIは、単体ユーザーの方で間違いないです。 https://developers.worksmobile.com/jp/reference/user-link-to-line-create?lang=ja 解決しましたので共有致します。 状況を正しく記載できておらず申し訳ございませんでした。 ■環境 グループ会社機能を利用(テナント1に対して複数のドメインを利用しています) ■APIの設定状況 仮に以下の3つのドメインがあったとして、CドメインにAPI2.0のアプリを作成していました。 そのため、Cドメインで作成したAPI2.0のアプリ情報(ServiceAccountによる利用)を利用してAPIを発行していました。 A 代表ドメイン B C ★API2.0のアプリを作成 ■今回の質問の件について Bドメインに存在するアカウントに対して、外部LINE権限付与を行うものでした。 ※利用するのは、Cドメインのデベロッパで作成したAPI2.0のアプリ情報(以降、CドメインAPI情報) ユーザーの部分更新(https://developers.worksmobile.com/jp/reference/user-update-patch?lang=ja) や ユーザーの削除(https://developers.worksmobile.com/jp/reference/user-delete?lang=ja) 等のAPIは、CドメインAPI情報でBドメインに存在するアカウントに対して、 APIを実行できておりました。 そのため、 外部LINE権限付与(https://developers.worksmobile.com/jp/reference/user-link-to-line-create?lang=ja) に関しても、同じようにCドメインAPI情報でAPI実行できるのかなと思って、実行した結果のHttpステータスコードが202でした。 ■解決 以下の2点から、対象者が所属するドメイン(今回の場合Bドメインで)でAPI2.0のアプリ情報を作成する必要がありそうと思い、 BドメインAPI情報を利用して、対象のAPIを実行したところ正しく権限が付与(Httpステータスコードも204で返ってきました)されていました。 ・外部LINE権限付与(https://developers.worksmobile.com/jp/reference/user-link-to-line-create?lang=ja) の公式上に、「ドメイン」というワードが登場すること。(但し、付与する対象者が所属するドメインで作成されたアプリ情報を使用しなさいとは記載されていない。) ・saitoさんのコメントにもあるすべてのユーザーに外部LINE権限付与(https://developers.worksmobile.com/jp/reference/user-link-to-line-all-create?lang=ja)の公式上に以下の記載があること。 「ドメインに属するすべてのユーザーに外部 LINE ユーザーとのトーク権限を付与する」 APIごとに、どのドメインで作成されたAPI2.0のアプリ情報だと実行できますよといった情報をドキュメント上で見つけられなかったので、どこに記載があるかご存じの方がいれば教えていただけると幸いです。 多分グループ会社機能を利用している利用者さんが少ないのと、 今回のようなAPI2.0アプリ情報の使い方はあまり想定していないのかもしれないです。
API 全般 2022.09.22