twitter認証の機能にて、ユーザー側が認証をキャンセルした時の対処が分かりません。

Question

#質問したいこと
ruby on railsにてtwitter認証処理を実装しているのですが、ユーザー側がキャンセルした際にエラーが発生しまいます。
キャンセル時の対処方法がわからず、誰か知っている方いましたら、ご教授お願いします。
ユーザー側が認証した場合は正常に動作することは確認しています。

#実行環境
Rails 5.2.2
ruby 2.4.1p111
oauth (0.5.4)
omniauth (1.9.0)
omniauth-oauth (1.1.0)
omniauth-twitter (1.4.0)
#エラーコード
Started GET "/auth/twitter" for 127.0.0.1 at 2019-03-26 11:09:23 +0900
Started GET "/auth/twitter" for 127.0.0.1 at 2019-03-26 11:09:24 +0900
Started GET "/auth/twitter/callback?denied=VGg0kgAAAAAA9nd5AAABabfCZc4" for 127.0.0.1 at 2019-03-26 11:09:32 +0900

OAuth::Unauthorized (401 Authorization Required):

vendor/bundle/gems/oauth-0.5.4/lib/oauth/consumer.rb:236:in token_request' vendor/bundle/gems/oauth-0.5.4/lib/oauth/tokens/request_token.rb:20:in get_access_token'
vendor/bundle/gems/omniauth-oauth-1.1.0/lib/omniauth/strategies/oauth.rb:56:in callback_phase' vendor/bundle/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:238:in callback_call'
vendor/bundle/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:189:in call!' vendor/bundle/gems/omniauth-1.9.0/lib/omniauth/strategy.rb:169:in call'
vendor/bundle/gems/omniauth-1.9.0/lib/omniauth/builder.rb:64:in call' vendor/bundle/gems/rack-2.0.6/lib/rack/tempfile_reaper.rb:15:in call'
vendor/bundle/gems/rack-2.0.6/lib/rack/etag.rb:25:in call' vendor/bundle/gems/rack-2.0.6/lib/rack/conditional_get.rb:25:in call'
vendor/bundle/gems/rack-2.0.6/lib/rack/head.rb:12:in call' vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/http/content_security_policy.rb:18:in call'
vendor/bundle/gems/rack-2.0.6/lib/rack/session/abstract/id.rb:232:in context' vendor/bundle/gems/rack-2.0.6/lib/rack/session/abstract/id.rb:226:in call'
vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/cookies.rb:670:in call' vendor/bundle/gems/activerecord-5.2.2/lib/active_record/migration.rb:559:in call'
vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/callbacks.rb:28:in block in call' vendor/bundle/gems/activesupport-5.2.2/lib/active_support/callbacks.rb:98:in run_callbacks'
vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/callbacks.rb:26:in call' vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/executor.rb:14:in call'
vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/debug_exceptions.rb:61:in call' vendor/bundle/gems/web-console-3.7.0/lib/web_console/middleware.rb:135:in call_app'
vendor/bundle/gems/web-console-3.7.0/lib/web_console/middleware.rb:30:in block in call' vendor/bundle/gems/web-console-3.7.0/lib/web_console/middleware.rb:20:in catch'
vendor/bundle/gems/web-console-3.7.0/lib/web_console/middleware.rb:20:in call' vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/show_exceptions.rb:33:in call'
vendor/bundle/gems/railties-5.2.2/lib/rails/rack/logger.rb:38:in call_app' vendor/bundle/gems/railties-5.2.2/lib/rails/rack/logger.rb:26:in block in call'
vendor/bundle/gems/activesupport-5.2.2/lib/active_support/tagged_logging.rb:71:in block in tagged' vendor/bundle/gems/activesupport-5.2.2/lib/active_support/tagged_logging.rb:28:in tagged'
vendor/bundle/gems/activesupport-5.2.2/lib/active_support/tagged_logging.rb:71:in tagged' vendor/bundle/gems/railties-5.2.2/lib/rails/rack/logger.rb:26:in call'
vendor/bundle/gems/sprockets-rails-3.2.1/lib/sprockets/rails/quiet_assets.rb:13:in call' vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/remote_ip.rb:81:in call'
vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/request_id.rb:27:in call' vendor/bundle/gems/rack-2.0.6/lib/rack/method_override.rb:22:in call'
vendor/bundle/gems/rack-2.0.6/lib/rack/runtime.rb:22:in call' vendor/bundle/gems/activesupport-5.2.2/lib/active_support/cache/strategy/local_cache_middleware.rb:29:in call'
vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/executor.rb:14:in call' vendor/bundle/gems/actionpack-5.2.2/lib/action_dispatch/middleware/static.rb:127:in call'
vendor/bundle/gems/rack-2.0.6/lib/rack/sendfile.rb:111:in call' vendor/bundle/gems/railties-5.2.2/lib/rails/engine.rb:524:in call'
vendor/bundle/gems/puma-3.12.0/lib/puma/configuration.rb:225:in call' vendor/bundle/gems/puma-3.12.0/lib/puma/server.rb:658:in handle_request'
vendor/bundle/gems/puma-3.12.0/lib/puma/server.rb:472:in process_client' vendor/bundle/gems/puma-3.12.0/lib/puma/server.rb:332:in block in run'
vendor/bundle/gems/puma-3.12.0/lib/puma/thread_pool.rb:133:in `block in spawn_thread'

  get 'auth/twitter'
  get '/auth/:provider/callback', to: 'authentication_management#twitter_auth'
  get '/logout', to: 'authentication_management#logout'

  def twitter_auth
    #以下で認証に関する処理を追加する。
    #取得したデータが不正でなければ、ユーザー登録(users/twitter_new)を実施する
    #現在は特になし
    #ユーザー登録処理で使用するために、フラッシュにデータを設定する。
    #そのまま渡すとデータサイズが大きすぎてエラーになるため、必要な分だけ渡す
    auth_data = request.env['omniauth.auth']
    flash[:twitter_provider] = auth_data[:provider]
    flash[:twitter_uid] = auth_data[:uid]
    flash[:twitter_name] = auth_data[:info][:name]
    redirect_to users_twitter_new_url
  end

#試したこと
・エラーコードにStarted GET "/auth/twitter/callback?denied=VGg0kgAAAAAA9nd5AAABabfCZc4
となっていたので、ルート設定を以下のように設定した。
before: GET "/auth/twitter/callback'
after: GET "/auth/twitter/callback/:denied'

・別の人の記事にget '/logout', to: 'service#entrance_screen'と記載があったので、これがキャンセル時のpost先かなと判断して記述してみたがエラーになってしまった。
logoutをsignoutに変更して試してもみました。

・rails twitter認証キャンセル時でググってみましたが、該当の記事がありませんでした。

・コードで示したtwitter_authアクションが通っているか確認するため、logを残すようにしましたが、logは出力されず通った形跡はありませんでした。

・twitter認証apiのアプリ作成時の設定にて、キャンセル時のurl等を入力する場所があるか確認しましたが、特にそれらしいものを入力する場所はありませんでした。

Answer 1

自分の経験では
gem 'omniauth'
gem 'omniauth-twitter'
gem 'twitter', "~> 4.8"
の時はrouteにget "/auth/failure"で動作しました。
get "/auth/failure", :to => '任意のコントローラー#任意のアクション'
ではないかと思います。

Comments

[xxkosukexx]

回答ありがとうございます。

さっそくget "/auth/failure"をルート設定しましたが、同じエラーが発生しました。
get "/auth/failure"にas: :auth_failure付与してみて試してみましたがダメでした。

また以下の設定も一応試してみましたが、エラーが発生しました。
get '/auth/validate_token(.:format)'
get '/omniauth/failure(.:format)', to: 'service#entrance_screen'

またgem 'twitter', "~> 4.8"を導入して試してみましたがダメでした。
gem 'twitter'でも試してみました。

[yut148]

回答にならず恐縮です。
あくまで推測ですが、現行動作しているので、こうなるとhttps://developer.twitter.com/側の設定でしょうか？

[xxkosukexx]

となるとこれがapikeyとsecretkeyを取得したときに設定した情報です。
※webサービス名や説明は一応伏せておきます。
<App Name>
WEBサービス名
<Description>
WEBサービスの説明
<Website URL>
http://（webサービス名）.com
<Sign in with Twitter>
Enabled
<Callback URL>
・http://localhost:3000/auth/twitter/callback
・https://(webサービス名).com/auth/twitter/callback
・http://127.0.0.1:3000/auth/twitter/callback
・http://(webサービス名).com/auth/twitter/callback
・http://localhost:3000/auth/failure
・http://127.0.0.1:3000/auth/failure
<Terms of service URL>
None
<Privacy policy URL>
None
<Organization name>
None
<Organization website URL>
None
<App usage>
I am creating a web service.
I am creating user authentication with that web service, but I am planning to use it to implement user authentication on twitter.

コールバックに/auth/failureを追加してみましたが、やはりダメでした。

<Terms of service URL>
<Privacy policy URL>
<Organization website URL>
上記３つにhttp://localhost:3000/auth/failureを入れてみましたが、そもそも設定するURLが正しくなく、弾かれしまいます。

これら以外に、キャンセルに関する設定は見当たらないように思います。。。
それとも、これ以外にも何か設定する必要があったりするのでしょうか？

[yut148]

ちょっと今はhttps://developer.twitter.com/に行けないので深夜近い時間となりますが自分の環境と見比べてみます。

[xxkosukexx]

わざわざ済みません。
助かります。。。

[yut148]

自分も以前ハマった事でPCの時間がずれているという事があったのですが、念の為サーバの時間はあってますか？

[xxkosukexx]

自分の知識が足りなく、サーバーが何を指しているのかいまいち理解できないてないですが、ローカル環境で開発を行なっていることを考えると、自pcの時間という認識でよろしいでしょうか？
それともhttpサーバーのpumaに時間に関する設定ができたりするんでしょうか？

また以下の記事で時間のずれによってtwitter認証で不具合が発生しているという記述を見つけたので、コメント欄の記述の内容を試してみようかと思います。
https://qiita.com/hirokishirai/items/5a43977a38ecd922bfb9

[xxkosukexx]

コンピュータの内臓時間を以下の記事で設定し直し、情報通信研究機構で内臓時間で差がないことを確認してからtwitter認証キャンセルをしましたが、やはりエラーが発生してしまいました。。。

時間の再設定　　　http://www.nict.go.jp/JST/JST5.html
情報通信研究機構　https://yoyunoyoshio.com/2016/07/14/macclock/

[yut148]

確認ありがとうございます。遅くなってすいません。ローカル開発されていればその環境の時刻とアクセスする側の時刻を指しました。御理解あっていると思います。自分のサイトの設定と見比べました。
気になった箇所はコールバックの設定箇所ぐらいです。自分の場合は
https://ドメイン/auth/twitter/callback
http://ドメイン/auth/twitter/callback
の2点だけでした。数が問題ではなく何かがあった気がしました。何かは思い出せないのですが。
Keys and tokensのタブとPermissionsのタブも確認してみましょうか。
関係ないとは思いますが念のため
Keys and tokensは開発環境とhttps://developer.twitter.com/とで差異はなくあってますでしょうか？
PermissionsはRead-only、Read and write、Read, write, and direct messagesどれでも作成中のサイトの仕様にあわせればいいと思いますが。

[xxkosukexx]

ご確認ありがとうございます。

＜コールバックurl＞
一応urlをローカル環境のもののみにして、再度twitter認証キャンセルを実施しましたがダメでした。
以下の２つのみに設定した。
・http://127.0.0.1:3000/auth/twitter/callback
・http://localhost:3000/auth/twitter/callback

<Keys and tokens>
api keyとsecret keyについては、なんども確認しましたので間違いはないです。
https://qiita.com/hirokishirai/items/5a43977a38ecd922bfb9
上記記事で、twitterアプリがsuspendされている可能性があるとあったので、twitterアプリを作り直して、再設定してみましたがダメでした。
Access token & access token secretという箇所もあるのですが、こちらはtwitter認証に利用するのでしょうか。
僕は使用しないと認識しているのですが。

<時間のズレが解消できていない可能性>
先日確認した時間のズレを再度今日確認してみましたが、時間にズレが発生していました。
先日は差がないと表示されていましたが、今日は何回設定し直しても時間にズレがあると表示されてしまいます。
以下のntpサーバーで時間の取得をしました。
・ntp.nict.jp
・ntp.jst.mfeed.ad.jp
・ntp1.jst.mfeed.ad.jp
・ntp2.jst.mfeed.ad.jp
・ntp3.jst.mfeed.ad.jp
・time.apple.com.(apple標準)
何が問題かわかったりしますでしょうか？

<通信環境による時間のズレの可能性>
情報通信研究機構で通信環境により、時間がずれる場合があると表記されています。単純に表示上ズレているだけで実際はズレていない、ならいいのですが、もし仮に通信環境によってpcと　twitterの時刻にズレが発生するだった場合は問題な可能性が考えられます。
pc時刻はズレていないにも関わらず
そう言った可能性はあるのでしょうか？
ちなみに自分はポケットwifiを利用しており、通信環境は良いとは言えません。そう言った可能性も考えられるのでしょうか？

<僕が開発しているrailsアプリ自体に不具合がある可能性>
もしかしたら僕が開発しているrailsアプリ自体に不具合がある可能性があります。（作り始めたばかりなので、あまりいじってないですが、）
twitter認証機能のみを実装したアプリを作成し、twitter認証キャンセルを行なった際にどうなるか確認してみたいと思います。

<開発環境によって発生している不具合の可能性>
もしかしたら、railsやrubyのversionによって発生している不具合の可能性も考えられます。
もしよろしければ、現在稼働しているアプリの開発環境を教えていただくことは可能でしょうか？
必要そうなもの
・ruby
・rails
・oauth (0.5.4)
・omniauth (1.9.0)
・omniauth-oauth (1.1.0)
・omniauth-twitter (1.4.0)

お手すきの時間で構いませんのでよろしくお願いします。

[yut148]

すぐ答えられる箇所で
<時間のズレが解消できていない可能性>
<通信環境による時間のズレの可能性>
は問題ないと思います。具体的には忘れましたが1日とかのずれではOAuth::Unauthorized (401 Authorization Required): が出ます。数分出たかはは計測した記憶もないです。http://www.nict.go.jp/JST/JST5.htmlと秒未満の誤差があっても動作すると推測します。
ちょっと他はすぐにわからないのでまた改めます。
キャンセル時のエラーとの事ですが、ログインは出来ていると理解してよろしいのでしょうか？
画面遷移上ログインで出来ていると誤認している事はありませんか？
誤認の確認ですがなんでもいいので、例えばユーザ情報等取得できますか？

[xxkosukexx]

言いたいことが理解できてなかったら申し訳ないのですが、twitter認証キャンセルで出ているエラーはOAuth::Unauthorized (401 Authorization Required):なのですが、これは1日のズレがある時に出るのでしょうか？

ログインの認識についてはユーザー名が取得できているため、それで認証ができていると認識しています。
取得したユーザー名を画面上に表示させていますが、異なったtwitterアカウントで認証処理を行い、twitterアカウントごとのユーザー名が画面上に表示されていることを確認しています。
アカウントのユーザー名を自分で設定して表示している処理はないので、アカウントのユーザー名が表示されている＝twitterの認証が完了している＝ログインできている
と認識しています。

ユーザー名が取得できている、ログインできているという認識であってますでしょうか？

ちなみに以下がtwitter認証時のrailsのdevelopment.logです

Started GET "/auth/twitter" for 127.0.0.1 at 2019-03-27 12:49:07 +0900
Started GET "/auth/twitter/callback?oauth_token=vWS18gAAAAAA9th5ABab1EDb0&oauth_verifier=1DRJvLXXHGSpsEr26zs3" for 127.0.0.1 at 2019-03-27 12:49:08 +0900
Processing by AuthenticationManagementController#twitter_auth as HTML
Parameters: {"oauth_token"=>"vWS18gAAAAAA9th5AAABab1EDb0", "oauth_verifier"=>"1DRJvLAXiLU42c30sfXXHGSpsEr26zs3", "provider"=>"twitter"}
provider:twitter name:(アカウント名が表示されています)
Redirected to http://localhost:3000/users/twitter_new
Completed 302 Found in 7ms (ActiveRecord: 0.0ms)

Started GET "/users/twitter_new" for 127.0.0.1 at 2019-03-27 12:49:09 +0900
Processing by UsersController#twitter_new as HTML
User Load (19.5ms) SELECT `users`.* FROM `users` WHERE `users`.`provider` = 'twitter' AND `users`.`uid` = '24609' LIMIT 1
↳ app/controllers/users_controller.rb:108
メソッド名{login_session} ログメッセージ{user_id:980190964 username:アカウント名が表示されています}
メソッド名{provider_registration_and_login} ログメッセージ{twitter認証後のログイン状態{user_id:980194username:アカウント名が表示されています}
Redirected to http://localhost:3000/command_management/show
Completed 302 Found in 306ms (ActiveRecord: 218.0ms)

当質問のエラーコードと比較して見る限り、認証に失敗しているように見えません。データも取得できているように思います。

実際のコード
def twitter_auth
auth_data = request.env['omniauth.auth']
logger.debug("provider:#{request.env['omniauth.auth'][:provider]} name:#{request.env['omniauth.auth'][:info][:name]}")
flash[:twitter_provider] = auth_data[:provider]
flash[:twitter_uid] = auth_data[:uid]
flash[:twitter_name] = auth_data[:info][:name]
redirect_to users_twitter_new_url
end

[yut148]

>これは1日のズレがある時に出るのでしょうか？
はい出ます。（ステータスまでは記憶していないのでもし違ったら申し訳ないです。）
ログインは出来ていて問題ありません。
他は自分の開発環境が手元にないので改めます。

今の回答で気になった箇所は
・http://127.0.0.1:3000/auth/twitter/callback
・http://localhost:3000/auth/twitter/callback
と改めて設定したのでhttp:での利用でいいのでしょうか。
https:は利用しないアプリケーションでしょうか。
特に問題ないですが、httpでアクセスしてテストしているのか気になりました。

[xxkosukexx]

すみません解決しました。。。
最初に教えていただいたget '/auth/failure'なんですが、開発環境で使用するにはconfigファイルの設定が必要だったみたいです。
本番環境では不要な設定みたいですね。

以下の記事を参考にしました。
https://github.com/omniauth/omniauth/wiki/FAQ#how-to-fix-oauthunauthorized-error-for-twitter-provider
https://qiita.com/nekogeruge_987/items/8bd307f9ae31f27c248a

またhttpsについてはそこらへんの知識がまだ浅く、よくわかっていない状態です。
調べてみて取り入れた方がいいと思ったら取り入れてみようと思います。

だいぶ長く付き添っていただいてありがとうございました!
感謝です!!

[yut148]

解決したのは何よりです。今後も上記の様々なわずかな違いで動作しないので御注意ください。（keyの作り直し等やcallbackの指定等）

[xxkosukexx]

確かにtwitter認証って少しのことでいろんな不具合が発生していることが理解できました。
また別の不具合が発生した際に、今回学んだことはめちゃくちゃ役に立ちそうです＾＾