Drupal

認可サービスは、安易な認可はできないから、ユーザー（リソースオーナー）を認証しないわけにはいかない。ブラウザだと、ログインとセッションで管理できるが、REST APIを使うアプリではセッションを用いないからDrupalの通常ログインは行えない。なのになぜ認可行為が行えるのかが謎だった。さらに考えると、認証はID＋パスワードと言う固定観念にとらわれていたことに気がついた。

コストパフォーマンスは悪くないと思いますので応援も兼ねてぜひポチッとお願いします。

DrupalによるOpenID connectの実装は複数ある。認証サーバーになるためにはSimple OAuth (OAuth2) & OpenID Connectが必要で、他の認証サーバーを利用する場合はSocial Authを使えば良い。では、Social Authに認証を委任した状態で認可サーバーになるためにはどうすればよいかで迷宮にはまっている。

従来同人誌版ででていたものの商業版が発売された。

Google等のSNS認証は最近一般的なものになった。Drupalでも対応は進んでいる。しかし、より信頼性の高いサービスにはできれば公的機関が管理するeIDの利用が望ましい。エストニアは電子政府で有名でeIDの利用を広く許している。そして、そういった高信頼性サービスの提供者である電話会社がDrupalでサイト立てているケースが有る。ちなみにこの記事は、12月10日のDrupalアドベントカレンダーに入稿がなかったためエントリーしたものです。

まだアドベントカレンダーに空きがあったので日本では翌日になってしまっているが、現在地タリンではまだ当日なのでエントリーすることにした

Business rulesモジュールは、私のDrupal人生を変えたものだ。デバッグ機能があって、ルールを書いて走らせると内部で何が起きているのかを知ることができる。それを見ていると、ああこういう構造で実装されているのかと得心できるのだ。反面的なのだが、バグに理解を深める力があることを改めて気付かされた。

ECA - New rules engine for Drupal 9+というセッションにどうしても出たくなったので4時起きした。早起きは三文の得であった。いや、衝撃的な体験となった。

フォームの投稿には、その後の処理が続く。つまり、複数の人から投稿されたデータを必要な範囲で見ることができるようにしなければいけない。一方で、必要な範囲を超えて見ることができないようにしないといけない。Drupal8以降では、Groupモジュールがこの問題の解決にも利用されているが、フォームのデータの扱いは一筋縄ではいかない。