ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

2007年～2011年ごろまで はてなダイアリー に書いてた記事を引っ越してきました。

データを操作する時の権限について

YakiBiki

つらつら考えながら、昨日寝る直前にこんなのを書いていた。
http://www.glamenv-septzen.net/pukiwiki/index.php?YakiBiki%A5%E1%A5%E2%2F2007-12-11
こーゆーのは、やっぱりWikiのシンプルで軽量なI/Fが良い。なんかはてダって、長文を書いていくとJavaScriptが裏で影響しているのか微妙に重くなっていくような気がする・・・。


で、昨日は上記の通り細かくマトリクスになるんじゃないかなーと思ってたんだけど。いくらなんでもここまでする必要はないだろうとも思う。というよりは、こうしたマトリクス判定は逆にマトリクスのパラメータを排他的にしないと意味がないし、実装も難しい気がする。
現実問題としてはマトリクスパターン、というよりはフィルタリング処理に近いと思う。つまり、A, B, C の組み合わせ、じゃなくて、Aのフィルタにかかって、それ以外でBのフィルタにかかって、さらにそれ以外でCのフィルタにかかって・・・みたいな。
例えばCRUD関連であれば、そりゃあ、sys権限を有しているユーザーはそれこそ何でも有りです。問題はgroup権限を有するユーザーであったり、自分が参加しているgroupの他のユーザーの所有物のデータをどうするかであったりするわけです。

つまり、フィルタ・・・もうちょっとかみ砕くと、権限に関する優先順位的な概念になるのかも知れません。
で、単純なCRUDだけを考えればまぁまだそれなりに考えやすいと思います。

  • Create : 各権限に於いてCreate出来るか、出来ないかだけ。
  • Refer, Update, Delete : 各権限 + groupに紐付くユーザー + 自分が所有者か

ところが、CategoryやThread、あるいはUserやGroupになってくると、すこしややこしくなってきます。
CategoryやThreadの場合、「名前の重複」という観点が入ってきます。例えば、CRUDを所有者毎に完全に分離した場合。見えるのも、編集できるのも自分の作成したモノのみ・・・完全にユーザー毎のprivateブログとして運用する場合ですね。この場合、名前の重複は有りになります。但し条件付きで、ユーザー内では重複不可、です。つまり、ユーザーにとっては自分が作成したCategory(/Thread)が世界の全てになるわけですので、その中での重複不可はユーザーにとって明白です。しかし、他のユーザーが作成したものと重複不可されても、ユーザーには他のユーザーのdataが見えませんので、なぜか分からないし、例え理由が分かったとしても理不尽に思えるかも知れません。
また、UserやGroupの場合システム根幹に関わってくる部分ですので、単純なCRUDとは行かなくなります。UserのCreateであれば、権限は自由に付与できるのか。Updateであれば、権限変更は？ステータス変更は？パスワード変更は？メールアドレス変更は？Groupの場合はユーザーの追加・削除で、さらにその対象として選べるユーザーの関係は？全ユーザーを好き勝手に追加・削除できるのか？自分だけか？自分と関係したgroupのメンバー？

・・・ややこしすぎるし、何か機能に振り回されている感じがしてきた。基本に戻ろう。
YakiBikiは何か？WikiとBlogのいいとこ取りをした、各記事に対してアクセスコントロールを柔軟に行えるツールだ。
じゃぁWikiとBlogの本質は？コラボレーションのツールだ。情報の共有を推し進めるツールだ。
そう、これが基本だ。しかし運用・管理の視点から、特にUser/Groupの絡みでどんどんややこしくなってきている。
もっとすっぱり割り切っても良いような気がする。割り切りが大切。特に今の段階では、割り切って作らないと前に進めなくなる・・・。

本来に戻ろう。というか、この辺は旧memoriesでやってたポリシーで良いような気がする。

  • User管理：sys権限のみ(個々のユーザーはprofileモジュールから変更する)
  • Group管理：sys, group権限(group権限は自分の作成したグループのみ変更可能)
    • 権限無しユーザーでも、一覧は全て表示される。新規作成・編集・削除アクションを行えない。
  • Category管理：新規作成は全ユーザーで可能。
    • sys権限は全ての編集・削除アクションを行える。
    • sys権限が無い場合は、自分が作成したCategoryのみ編集・削除アクションを行える。
  • Thread管理：新規作成は全ユーザーで可能。また、その際選択できるACLはU2AインデックスでREADレベルのもの。
    • sys権限は全てのThreadを一覧表示・編集・削除できる。
    • sys権限が無い場合、個々のユーザーでU2AでREADレベルがdefault_aclとして設定されているThreadを表示できる。
    • sys権限が無い場合、個々のユーザーでU2AでREADWRITEレベルがdefault_aclとして設定されているThreadを編集・削除できる。

ちなみに、Threadのdefault_aclと記事のACLは少し関係している。

  • 記事のACL
    • READ : 記事を表示できる。
    • WRITE : 記事を編集できる。属性も込み。
  • Threadのdefault_aclはThread絞り込み、あるいは記事を表示した時のThreadの表示方式に関わります。
    • NONE : そのThreadで絞り込みできない。記事を表示している時は、Thread名が表示されない。また、故意にIDを指定しても絞り込みできない。つまり記事自体のACLでは許可されているが、そのThreadには何のレベルも無い場合、そのThreadは「見えない」。
    • READ : そのThreadで絞り込みできる。記事を表示している時は、Thread名が、Thread絞り込みモードへのリンクになる。
    • READWIRTE : そのThreadに属する新規記事を作成できる。Thread絞り込みでは新規作成のリンクが表示されるし、通常の新規作成の場合も、Threadのリストに表示される。

ちなみに、新規記事を作成した時にThreadも新規作成した場合、その記事のACLが、新規作成されたThreadのdefault_aclになる。

うーん、こんな感じで、今は良いんじゃないかな。あのー、アレだ。ユーザーやグループ情報は、データファイルの場所を設定できるようになっているので、例えばユーザー毎にディレクトリを分けようとした時も、そこは共通化できたりしちゃうわけだ。
えーっと、つまり、CategoryやThread情報はユーザー個別に作成したディレクトリに放り込んでしまうとかすれば、ユーザーは自分のしか見えないし、システムとしてもそれがその世界の全てになる。でも、ユーザーとグループデータは共通ファイルにしてしまえば、それらの情報は外の世界と連携できる。で、ACL「のデータ」自体もユーザー毎に分離しちゃっても良いし、システム（というかサイト）全体で一箇所にまとめておいても良い。

つまり、YakiBikiとしてのポリシーさえしっかり打ち出していれば、ユーザーの方で色々弄ってくれる。そう。いつだって、ユーザーの方が数は多くて、一番知恵をひねり出してくれるのはユーザーなのだから。

ユーザーを信じよう。またまた忘れかけていた、初心。

・・・いえ、責任転嫁じゃないですよ？