問題タブ [doorkeeper]

構築しているRailsベースのAPIでクライアントアプリケーションを管理するためにDoorkeeperを使用しています。アクションが処理しているリクエストを送信したクライアントアプリに関する情報を確認したいコントローラーアクションがあります。

Doorkeeperは、リクエストを処理しているDoorkeeper :: Applicationに（コントローラーで）アクセスするためのヘルパーまたはその他の簡単な方法を提供しますか？Deviseの「current_user」メソッドに類似したものを想定しています。

そのようなヘルパーが存在しない場合、どうすればこの情報を取得できますか？

これがoauthの初心者の質問である場合は申し訳ありません

ここの例に基づいて、devise +doorkeeperを使用してoauth2APIを実装しました： https：//doorkeeper-provider.herokuapp.com/およびここ：https ： //github.com/applicake/doorkeeper-devise-client

改ページ可能な取引のリストを返すAPIエンドポイントを提供できるようにしたいのですが、コードは次のとおりです。

ただし、クライアント側では、次のようなページパラメータを渡すことはできません：/explore/deals.json?page=3

何らかの理由で、ページパラメータがプロバイダーに表示されません。誰かが私を助けてくれますか？

Doorkeeper と Omniauth を使用しています。クライアントは認証エンドポイントにリダイレクトし、認証エンドポイントはログイン ページにリダイレクトします。ユーザーは Facebook での認証を求められた後、ログインされ、フローは Doorkeeper に戻ります。

私の問題は、ユーザーがサインインしないことを選択した場合、フローが Doorkeeper に戻らないことです。フローが Doorkeeper に戻り、Doorkeeper がクライアントにエラーを返すことを期待します。

どうすればいいですか？

Doorkeeper.rbには、認証ブロックがあります。このロジックをそこに収める必要がありますが、Rubyの構文はまだ新しいので、どのように書くかわかりません。

その人がログインしていて、それらがcurrent_userであるか、以下のロジックが実行されます。

「Authorize」ボタンを押すと、「Called id for nil」が表示されます

認証コントローラーで問題が発生している行は次のとおりです。

エラーページで Auth が nil になっています:

ここに私のリクエストパラメータがあります:

また、承認/拒否フォームを表示したときに @pre_auth 変数に含まれる内容は次のとおりです。

私は Doorkeeper を使用してcurrent_userいますが、何らかの方法で変更を加えた場合、たとえば、unless または if を使用して条件ステートメントに入れると、Doorkeeper はそれを取得しません。current_user ||セッション ストアを含む次の 2 行を保持して適合させ、二重パイプの右側の 1 行で動作するようにリダイレクトする簡単な方法はありますか?

私は答えを見つけるためにたくさんグーグルで検索しましたが、答えを見つけることができません。この依存関係の問題を解決するにはどうすればよいですか。sass-rails を削除すると (実用的ではなく、問題をテストするためだけに)、Gemfile が依存関係の競合を持つ coffee-rails にロールダウンされるだけです。

Gemfile.lock を削除して、バンドルのインストールをやり直しました。喜びはありません。

doorkeeper gem (または OAuth 一般) を使用して特定の OAuth トークンにバインドされるユーザー設定を格納する統一された方法はありますか?

同じトークンが使用されている限り、ユーザーがログイン時にロケールを選択できるようにしたいと考えています。私のユースケースでは、ユーザー固有ではなくセッション固有の設定が必要です.1人のリソース所有者に複数のトークンを発行し、異なる設定にすることができます。

Rails アプリで OAuth を提供するために Doorkeeper gem を使用しています。クライアントは Chrome 拡張機能です。

「use_refresh_token」を doorkeeper.rb でコメントアウトし、「access_token_expires_in」を 1 分に設定しました。1分後にクライアントに再認証を強制すると思いました。ただし、use_refresh_token が存在するかどうかに関係なく、再認証は自動的に行われます。

use_refresh_token が存在する場合、アクセス トークンの有効期限が切れるたびに新しい行が「oauth_access_tokens」に追加されます。「oauth_access_grants」に新しい行は追加されません。

use_refresh_token をコメントアウトすると、新しい行が両方のテーブルに追加されます。クライアントが手動で再認証していた場合に期待することです。しかし、それは自動的に行われているようです.OAuthログイン画面からアプリを再認証することなく、ユーザーはアクセスを許可されます.

無知で申し訳ありませんが、私は Doorkeeper と OAuth の両方に慣れていないため、Google などで手がかりが見つかりませんでした。