graphql-rubyのAuthorizationに関する学習メモ
Authorization
https://graphql-ruby.org/guides#authorization-guides
概要
Authorization: GraphQL vs REST
- REST APIはリクエストされたアクションの直前に、クライアントがそのアクションに対して権限を持っているかを判断する。
- この考え方はGraphQLではマッチしない。その理由は、GraphQLの場合はコントローラが一つしかないため。
class GraphqlController < ApplicationController def execute # すべてのqueries、mutationsがここを通るため、この段階でどのような権限が必要か判断できない if current_user.can?(:"???") MySchema.execute(query_str, context: ctx, variables: variables) end end end
では、どのような考え方をするべきか?
- queriesの場合、取得するオブジェクトに対する権限を持っているか
- mutationsの場合、それぞれのmutationを実行する権限があるか
GraphQLにおける認証
そもそも認証とは?
- 認証とは、どのユーザーが現在のリクエストを行っているかを判断するプロセスのこと。例えば、usernameやpasswordによる確認、sessionによる確認など。
- 認可とは、現在のユーザーが何をする/見る権限を持っているかを確認するプロセスのこと。例えば、admin?ステータスの確認やデータベースからの権限グループの検索。
認可の例 (https://graphql.org/learn/authorization/より)
Only authors can see their drafts
認証はGraphQLでは扱われていない。代わりに、コントローラはHTTPリクエスト(例えば、HTTPヘッダやクッキー)に基づいて現在のユーザを取得し、その情報をGraphQLクエリに提供する。そうすれば、GraphQLのコードにおいて、current_userはcontext[:current_user] でアクセスできる。
class GraphqlController < ApplicationController def execute context = { current_user: current_user } MySchema.execute(query_str, context: context, ...) end end
ビジネスロジックに認可を委任する
リンク先参照
オブジェクト指向のこころ - 12章 エキスパートはどのように設計するのか?
勉強用メモ
概要
- Alexanderの設計アプローチを学ぶ
- まず全体像を捉え、そこから詳細やそれらの関連を探っていくというアプローチ
まとめると?
建築学においても、中庭、車庫、玄関、トイレなどの概念を洗い出し、それらが使われる場面・コンテキストを把握し、大まかな関連(配置)を決定した後、それぞれの詳細を考える。その詳細を考えながら大枠との整合性は取れているか、大枠と詳細を行ったり来たりしながら詰めていく。この考え方をソフトウェアにも応用する。
オブジェクト指向のこころ - 11章 Abstract Factoryパターン
勉強用メモ
書籍のUML図ないと、これだけ見ても何もわからないな...
Abstract Factoryパターンとは
- オブジェクトの生成と使用の責務を分ける
- 状況に応じてオブジェクト群を使い分ける際に用いる
switchやif分岐は抽象化を示す赤信号の可能性
- アルゴリズムや利用するオブジェクトの選択するための分岐は危険
- 高い結合度と低い凝集度により、メンテナンスコストが上がり、カオスになりがち
- 特に、ある変数が複数のswitchに使われ、switch同士が結合した時
下記で "MIDDLE" が増えた場合にどうする?
if RESOLUTION = "LOW" # 処理 elsif RESOLUTION = "HIGH" # 処理 end
安易な継承も赤信号。将来的に組合せ爆発が発生するから。
税計算の問題でも同様のことが記述されていた。ifやswitchによる処理の分岐や、継承による問題の解決には危険が潜んでいることが繰り返し述べられている。
どうすればいい?
- Bridgeパターンで学んだように、共通性/可変性分析でオブジェクト群に分ける
- それらのオブジェクト群を使用する側、使用される側に分けて設計する
ここで新たな問題、「適切なオブジェクトをどうやって生成するのか?」が生まれる。
必要なオブジェを実体化するFactoryオブジェクトを用意する。
オブジェクト指向のこころ - 10章 Bridgeパターン
勉強用メモ
P.152以前は電車で
継承の多用はNG
- 流動的要素をクラス継承で扱うのは間違え。クラス数の爆発が発生する
- オブジェクトを責務で考え、集約を多用することが正しい
- 流動的要素をカプセル化する
パターンを導き出す
- まずは、共通性/可変性分析で流動的要素を洗い出す cf.図10.9(P.158)
- 次に、クラス群の関連性を考える。一方のクラス群からもう一方を使用する
オブジェクト指向のこころ - 6章 Facadeパターン
勉強用メモ
Facadeパターンとは
Facadeとは「建物の正面(窓口)」、「見せかけ」等の意味を持つ。
- 問題:複雑なサブシステム群があり、クライアントはどのメソッドを呼び出せばいいか把握できない
- 目的:理解しやすいインターフェースを提供し、クライアントが理解しやすく呼び出しやすくする
Facadeパターンの利用場面
- 呼び出し方法の簡易化:既存システムの学習コストが高く、簡潔なインターフェースを作成したい
- システムの利用状況の追跡:特定のシステムに対するアクセスをFacade経由にする
- システムの交換や刷新:既存クラスをFacadeのprivateメソッドにしておけば、クライアント側へ影響を最小限にできる
CAD/CAMの問題とFacadeパターンの関連
- V1SlotやV1HokeがV1Systemを使用する場面で上手く使える