0

LTI ツール プロバイダーに取り組んでいます。LTI認証パッケージを実装し、署名に一致する 2 つ (..1 つ?) のレッグ OAuth を正常に取得できました。1 つの重要なことを除いて、リダイレクトしても問題ありません。

私ができるようになりたいのは、

  • このユーザーが存在しない場合は、作成してログインします
  • ユーザーが存在する場合は、ユーザーにログインします

現在、クライアントルートにリダイレクトすると、実際にユーザーを特定する方法がありません。

LTI コンシューマーは、次のような Iron Router サーバー ルートを指します。

Router.route('/lti', { where: 'server' }).post(function() {
    provider.valid_request(request, function(error, valid) {
        if (valid) {
            this.response.writeHead(302, { Location: '/' });
        } else {
            this.response.writeHead(403);
        }
    });
    return this.response.end();
});

これを簡単に機能させるために使用できるパッケージはありますか? accounts-base のようなものを使用できますか? 独自のロジックを実装する必要がありますか?

どんな助けや指示も大歓迎です。

乾杯。

4

1 に答える 1

1

accounts-baseメソッドを使用してカスタムログインハンドラーによって処理される、使い捨ての認証トークンシステムを実装することで、これを解決しましたAccounts.registerLoginHandler。

大まかな認証フローの概要:

LTI ルート (サーバー)

  1. 認証されたら、新しいアカウントを作成する/古いアカウントを更新する
  2. トークン + タイムスタンプ オブジェクトをコレクションに挿入します。
  3. 認証ルートにリダイレクトし、トークンをパラメーターとして渡します

認証ルート (クライアント)

  1. ユーザーがログインしているかどうかを確認します。ログインしている場合は、ホーム ルートにリダイレクトします
    • トークンが提供され、存在する場合は、使用済みとしてマークします。サーバールートでユーザーを確認する方法がないため、ユーザーがセッションを持っていて、LMS を介してリンクを閉じて再度開いた場合、余分なトークンを処理する必要があります。
  2. ユーザーがログインしていない場合は、トークンを確認してください。存在する場合は、それをカスタム認証に渡しますAccounts.callLoginMethod
  3. カスタム ログイン ハンドラがトークンを検証します。正当な場合は、トークンを消費してユーザーをログインさせます。

私のコードはごちゃごちゃしていますが、リファクタリングするときはおそらく Meteor パッケージとしてオープン ソース化するでしょう。

于 2015-10-22T10:00:16.957 に答える