memo.log

技術情報の雑なメモ

RailsでTimeTreeにOAuthする最低限の手順メモ

TimeTreeはAPIの利用にOAuthかパーソナルアクセストークンの利用が可能となっているが、今回はOAuthをRailsから利用する形で確かめてみたので、手順をメモしておく。

こんな感じで、Railsアプリ上のリンクを踏むと、TimeTreeのOAuth認証に飛び、ログインするとRailsアプリに戻ってくる。 Railsアプリの方では返ってきた時にアクセストークンの取得ができるので、それを利用してAPIを操作できる。 今回はコールバック後、そのままトップページに戻るだけのサンプルだが実際にはRais側でもログイン認証的な処理を行うことを想定する。

f:id:kuredev:20210922122704g:plain

以下のgemを使わせていただく。

github.com


Railsインストール

以下にしたがってインストール&実行&Webアクセスできることを確認しておく

docs.docker.com

TimeTree 設定

以下からコンソールにアクセスし、「OAuth Apps」を作成する。 作成後、「連携情報」の「Redirect URL」に、Railsのログイン認証後のcallback用のURLを記載する。 「クライアントID」「クライアントシークレット」は控えておく。

developers.timetreeapp.com

Rails設定

route の追加

トップページと、コールバックのルートを追加しておく

root "welcome#index"
get "/auth/:provider/callback" => "sessions#create"

コントローラ追加

トップページ用のコントローラ

class WelcomeController < ApplicationController
  def index
  end
end

コールバックで処理するコントローラ

class SessionsController < ApplicationController
  def create
    # 認証後に取得できるトークン等、取れる
    # pp request.env
    redirect_to root_path
  end
end

ビュー追加

トップページのファイルに以下追加 views/welcome/index.html.erb

<%= link_to "TimeTree(OAuth)", "/auth/timetree", method: :post %>

OAuth関連追加

config/initializers/omniauth.rb

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :timetree, "[クライアントID]", "[クライアントシークレット]"
end

Gemfile に以下追加し、 bundle install

gem "omniauth-timetree"
gem "omniauth-rails_csrf_protection"

以上で動作するはず。

Webrick でレスポンスでわざとWait(遅延)を入れる

そんなオプションは無さそうだったので、無理くりライブラリに手を入れるとすると、以下らへんでレスポンスしているようだったので、★部分あたりに sleep を挟めば一応意図どおりにはふるまってくれる。

        ensure
          if req.request_line
            if req.keep_alive? && res.keep_alive?
              req.fixup()
            end
            sleep 5 # ★
            res.send_response(sock)
            server.access_log(@config, req, res)
          end

webrick/httpserver.rb at master · ruby/webrick · GitHub

EC2インスタンスにセカンダリIPv4アドレスを付与しただけでパケットは届く

OSでセカンダリIPアドレスを処理できるようにしないと処理はできないが、パケット自体はインスタンスまで届くようだ。 パケットキャプチャでPing確認したらパケットは届いてた。(返信はしなかった)

参考

aws.amazon.com

【Amazon VPC】あるホスト宛のパケットがIPアドレスが誤っていてもMACアドレスが合っていて送信元先チェックが無効なら届く(同サブネットのアドレスでもOK)

表記のとおりだが、意外な結果だった。 別サブネットでVPC外宛のルートをルートテーブルで特定ホストに向ける構成(FWみたいな)はよく見かけるが、例えばVPCのCIDR内の別のIPアドレス向けの通信でMACアドレスだけ正しくして特定ホストに届くのか、というと微妙だが届いた。ルートテーブルにくわれるか、VPCの制限的にドロップされるかと思いきや、ENIが持っていないIPアドレスでも届くようだ。

【Amazon VPC】あるホスト(IPアドレス)宛のパケットの宛先MACアドレスの値が誤っているとパケットは届かない。

物理ネットワークでは当然のことだが、VPCで送信元先チェックを無効にしていればワンチャン届いたりするのか?と思ったが、やはり届かなかった。

検証方法としては↓のソースで宛先MACアドレスをわざと誤ったものに編集して送信し、受けて側で tcpdump してパケットが届くか確かめた。 github.com

多分VPCのMapping Serviceで行き先不明のパケットとしてドロップされているのかな。

【Ruby】AF_PACKET / SOCK_RAWでPingを実装してみた

github.com

  • AF_PACKET / SOCK_RAWの場合、 Ethernetヘッダから指定する
  • プロトコル部は一応 Socket::ETH_P_IP を指定したけど、多分なんでもいいっぽい。(イーサヘッダから自分で指定するのでどちらにしても自分で指定することになるからかな)