QOAuthUriSchemeReplyHandler Class
プライベート/カスタムおよびhttps URIスキームのリダイレクトを処理する。詳細...
Header: | #include <QOAuthUriSchemeReplyHandler> |
CMake: | find_package(Qt6 REQUIRED COMPONENTS NetworkAuth) target_link_libraries(mytarget PRIVATE Qt6::NetworkAuth) |
qmake: | QT += networkauth |
Since: | Qt 6.8 |
Inherits: | QOAuthOobReplyHandler |
プロパティ
- redirectUrl : QUrl
パブリック関数
QOAuthUriSchemeReplyHandler() | |
QOAuthUriSchemeReplyHandler(QObject *parent) | |
QOAuthUriSchemeReplyHandler(const QUrl &redirectUrl, QObject *parent = nullptr) | |
virtual | ~QOAuthUriSchemeReplyHandler() override |
void | close() |
bool | isListening() const |
bool | listen() |
QUrl | redirectUrl() const |
void | setRedirectUrl(const QUrl &url) |
シグナル
void | redirectUrlChanged() |
詳細説明
このクラスは、OAuth 2.0 の認証処理でプライベート/カスタム URI または HTTPS URI スキームを使用してリダイレクトを行う際のリプライハンドラとして機能します。認可リダイレクトの受信 (コールバックとも呼ばれます) と、それに続くアクセストークンの取得を管理します。
リダイレクトURIは、認可サーバーがフローの認可部分が完了すると、ユーザーエージェント(通常、好ましくはシステムブラウザ)をリダイレクトする場所である。
特定のURIスキームの使用は、URIを正しいアプリケーションに関連付けるた めに、オペレーティングシステムレベルでの設定を必要とする。この関連付けの設定方法は、オペレーティングシステムによって異なる。Platform Support and Dependencies を参照のこと。
このクラスはQOAuthHttpServerReplyHandler を補完するもので、http
スキームをローカルホスト・サーバーの設定によって処理する。
次のコードは、その使い方を示している。まず、必要な変数:
QOAuth2AuthorizationCodeFlow m_oauth;
QOAuthUriSchemeReplyHandler m_handler;
続いてOAuthのセットアップ(簡潔のためエラー処理は省略):
m_oauth.setAuthorizationUrl(QUrl("https://some.authorization.service/v3/authorize"_L1)); m_oauth.setAccessTokenUrl(QUrl("https://some.authorization.service/v3/access_token"_L1)); m_oauth.setClientIdentifier("a_client_id"_L1); m_oauth.setScope("read"_L1); connect(&m_oauth, &QAbstractOAuth::authorizeWithBrowser, this, &QDesktopServices::openUrl); connect(&m_oauth, &QAbstractOAuth::granted, this, [this]() { // Here we use QNetworkRequestFactory to store the access token m_api.setBearerToken(m_oauth.token().toLatin1()); m_handler.close(); });
最後に、URIスキームのreply-handlerを設定します:
m_handler.setRedirectUrl(QUrl{"com.my.app:/oauth2redirect"_L1}); m_oauth.setReplyHandler(&m_handler); // Initiate the authorization if (m_handler.listen()) { m_oauth.grant(); }
プライベート/カスタムURIスキーム
カスタムURIスキームは通常、逆ドメイン表記にパスが続くか、場合によってはホスト/ホスト+パスを使用します:
// Example with path: com.example.myapp:/oauth2/callback // Example with host: com.example.myapp://oauth2.callback
HTTPS URIスキーム
HTTPS URIスキームでは、リダイレクトURLは通常のhttpsリンクになります:
https://myapp.example.com/oauth2/callback
これらのリンクは、iOSではユニバーサルリンク、Androidではアプリリンクと呼ばれます。
https スキームの使用は、アプリケーション開発者に使用する URL の所有権を証明させることで、さらなるセキュリティを提供するため推奨されます。この証明は、オペレーティングシステムが内部の URL ディスパッチの一部として参照する関連ファイルをホストすることによって行われます。
このファイルの内容は、アプリケーションと使用されるURLの関連付けを行います。関連ファイルは、HTTPリダイレクトなしで一般にアクセス可能でなければならない。さらに、ホスティングサイトは有効な証明書を持っている必要があり、少なくとも Android では、ファイルはapplication/json
content-type として提供される必要があります(サーバーの設定ガイドを参照してください)。
さらに、https のリンクにはユーザビリティ上の利点もあります:
- https URL は、通常の https リンクとしても機能します。https の URL は、通常の https のリンクとしても機能します。ユーザがアプリケーションをインストールし ていない場合(その URL はアプリケーションによって処理されていないため)、https のリンクは、例えば、インストー ルするように指示することができます。
- URL を開くためのアプリケーション選択ダイアログは回避され、代わりにアプリケーションが自動的に開かれます。
その代償として、この一般公開された関連ファイルをセットアップする必要があるため、余計なセットアップが必要になります。
プラットフォームのサポートと依存関係
現在サポートされているプラットフォームは、Android、iOS、macOSです。
URI スキームのリスニングはQDesktopServices::setUrlHandler() とQDesktopServices::unsetUrlHandler() に基づいています。これらは現在 Qt::Gui モジュールによって提供されているため、QtNetworkAuth モジュールは Qt::Gui に依存しています。QtNetworkAuth が Qt::Gui なしでビルドされた場合、QOAuthUriSchemeReplyHandler は含まれません。
アンドロイド
Androidでは URI スキームが必要です:
- アプリケーション マニフェストでintent-filters を設定する
- オプションとして、https スキームでの自動検証のために、サイト関連付けファイルをホストする。assetlinks.json
Qt Android Manifest File Configuration も参照してください。
iOS と macOS
- サイトの関連付けの設定entitlement
- https スキームでは、site association file (
apple-app-site-association
) をホストします。
Windows、Linux
現在サポートされていません。
プロパティ Documentation
redirectUrl : QUrl
このプロパティは、認証のリダイレクト/レスポンスを受け取るために使用される URL を保持します。
このプロパティは、認可リクエストの一部として送信されるOAuth2 redirect_uri パラメータとして使用されます。redirect_uri
は、デフォルトのオプションを指定してQUrl::toString() をコールすることで取得できる。
認証サーバーは、redirect_uri が不一致の場合は拒否する可能性が高いので、URL は認証サーバーに登録されているものと一致しなければなりません。
同様に、このハンドラがリダイレクトを受け取るとき、リダイレクト URLはここで設定されたURLと一致しなければならない。ハンドラはスキーム、ホスト、ポート、パス、そしてこのメソッドで設定された URLの一部であるクエリー項目を比較します。
これらすべてが一致した場合にのみ、URLは処理される。クエリパラメータの比較では、サーバ側で設定された追加のクエリパラメータは除外されます。
アクセス関数:
QUrl | redirectUrl() const |
void | setRedirectUrl(const QUrl &url) |
Notifierシグナル:
void | redirectUrlChanged() |
メンバ関数ドキュメント
QOAuthUriSchemeReplyHandler::QOAuthUriSchemeReplyHandler()
空のcallback()/redirectUrl() と親を持たない QOAuthUriSchemeReplyHandler オブジェクトを構築する。構築されたオブジェクトは自動的にリッスンしません。
[explicit]
QOAuthUriSchemeReplyHandler::QOAuthUriSchemeReplyHandler(QObject *parent)
parent および空のcallback()/redirectUrl() を持つ QOAuthUriSchemeReplyHandler オブジェクトを構築します。構築されたオブジェクトは自動的にリッスンしない。
[explicit]
QOAuthUriSchemeReplyHandler::QOAuthUriSchemeReplyHandler(const QUrl &redirectUrl, QObject *parent = nullptr)
QOAuthUriSchemeReplyHandler オブジェクトを構築し、parent を親オブジェクトとして、redirectUrl をリダイレクト URL として設定します。構築されたオブジェクトは自動的にリッスンを試みます。
redirectUrl()、setRedirectUrl()、listen() およびisListening()も参照 。
[override virtual noexcept]
QOAuthUriSchemeReplyHandler::~QOAuthUriSchemeReplyHandler()
QOAuthUriSchemeReplyHandler オブジェクトを破棄します。このハンドラを閉じます。
close()も参照 。
void QOAuthUriSchemeReplyHandler::close()
このハンドラに、着信 URL のリッスンを停止するように指示します。
listen() およびisListening() も参照 。
[noexcept]
bool QOAuthUriSchemeReplyHandler::isListening() const
このハンドラが現在待ち受け中の場合はtrue
を返し、そうでない場合はfalse
を返します。
bool QOAuthUriSchemeReplyHandler::listen()
このハンドラに、URLの入力を待ち受けるように指示する。リスニングに成功した場合はtrue
を返し、そうでない場合はfalse
を返す。
このハンドラは、URLをredirectUrl() にマッチさせる。受信したURLが一致しない場合は、QDesktopServices::openURL()に転送されます。
アクティブリスニングが必要なのは、最初の認証フェーズを実行するときだけで、通常はQOAuth2AuthorizationCodeFlow::grant() 呼び出しによって開始されます。
認証に成功したら、リスナーを閉じることを推奨します。リスニングはacquiring access tokens では必要ありません。
本書に含まれる文書の著作権は、それぞれの所有者に帰属します。 本書で提供されるドキュメントは、Free Software Foundation が発行したGNU Free Documentation License version 1.3に基づいてライセンスされています。 Qtおよびそれぞれのロゴは、フィンランドおよびその他の国におけるThe Qt Company Ltd.の 商標です。その他すべての商標は、それぞれの所有者に帰属します。