LIFF 的 Devise 相容性

[elct9620]

看到 Roadmap 裡面有要整合 Devise 之前有做過 Warden::LINE 能夠提供 Devise 的相容性整合，不知道有沒有興趣組進去？

概念原型： https://blog.frost.tw/posts/2021/09/21/liff-with-login-base-on-ruby-on-rails/

後來有改良過，可以跟 Devise 一起運作，基於 LIFF ID Token 認證使用者，也不影響原本 Devise 的功能。

module LIFF
  class SessionsController < LIFF::BaseController
    skip_forgery_protection only: :create
    skip_before_action :ensure_liff_user!, only: :create

    def create
      # TODO: Rewrite Warden::LIFF to support Devise
      if warden.authenticate(:line, scope: :line)
        @user = LIFF::UserFinder.new(warden.user(:line), referrer: current_referrer).perform
        sign_in @user
        head :no_content
      else
        head :unauthorized
      end
    end
  end
end

[etrex]

目前在 kamigo_demo 寫了一個串接 LINE Messaging API 和 LIFF 的登入方式，還沒寫成 Gem 但此寫法已在幾個專案上穩定使用。

source_user_id 是來自於 kamiliff 的 controller，對應的前端程式碼在這裡。

但這裡使用的是不安全的機制。

Kamigo 使用了相同的 params 所以 Devise 的登入只需要吃 source_user_id 就能同時完成 LINE Messaging API 和 LIFF 的自動登入。

改為 LIFF ID Token

應取得來自前端的 id token 後，於 kamiliff 的 controller 去跟 LINE 進行 ID Token 交換個資

就安全了。

[etrex]

Kamiliff 的設計並沒有相關文件，在一些簡報裡面有做到這張概念圖

目標是在後端一開始就能拿到 user id

使用 Kamiliff 一定會有 secondary redirect ，細節實作在這裡：https://github.com/etrex/kamiliff/blob/master/app/controllers/liff_controller.rb#L20-L58

這裡處理了一些不同 liff js sdk 版本的相容，沒有文件，不記得哪一行解決了哪一個版本的什麼問題。

[elct9620]

@etrex 我看 kamiliff 是直接 Decode JWT 的樣子，印象中官方文件不推薦這個方式，還是建議打一次 API 拿到確認過的，這邊是有什麼考量嗎？

---

Secondary Redirect 感覺是躲不掉，我的做法也會遇到

[etrex]

@elct9620 文件在此：https://developers.line.biz/en/docs/liff/using-user-profile/#use-user-info-on-server

理由：不應相信來自 client 的任何資料

[elct9620]

那現在 kamiliff 的做法會改掉嗎 XD

[etrex]

kamiliff 的做法近期會改為透過 ID Token 取得 User 資訊

User 資訊一樣會出現在原本的介面上，保持向下相容，介面不變，所以對於套件的用戶來說，可以先用，到時候再 update 就可。

[etrex]

目前還在考慮 Kamigo 串接 Devise 的部分抽取出 Gem 的必要性，因為感覺蠻容易串接的，很有可能只要寫一份文件就好。

[etrex]

@elct9620 kamiliff 0.26 加入了用 id token 進行 server side 驗證的實作：https://github.com/etrex/kamiliff/blob/master/app/controllers/liff_controller.rb#L94