Drupal

自治体は民間に比べるとサービスメニューが広いし、民間では採算に乗らないようなユーザーの少ないサービスも必要となる。だから、Webサイト構築の難易度も高い。各自治体で一からつくるのは現実的ではないし、どこぞの企業に独占させるのは避けるべきだ。だとすると、基盤部分は無償のオープンソースに移行したほうが良いだろう。スキーマが整理されれば、民間企業もそれに合わせることで生産性向上が期待できる。

NodeとTerm、どちらで定義すればよいか迷うことが少なくない。Drupal 8/9ではどちらで定義してもほぼ同様の結果を享受できる。ではその本質的な違いは何なのかを考えてみたら、意外な結論にたどり着いたので間違いがあるかも知れないけれど記事にしておくこととした。

Content typeでData typeを定義するのは重すぎると思っていたので、このモジュールに好感。

認可サービスは、安易な認可はできないから、ユーザー（リソースオーナー）を認証しないわけにはいかない。ブラウザだと、ログインとセッションで管理できるが、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アドベントカレンダーに入稿がなかったためエントリーしたものです。

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