アクセス関数のフック

コメントありがとうございます。

なるほど、hook_access()の、hookはnodeタイプを指定すべきなのですね。
例えば、hook_nodeapi()の場合、hookにはモジュール名を指定しますが、hook_access()も同様だと考えていました；

func_nodeapi() は、定義さえすれば全ノードについての_nodeapi()をフックできますが、
func_access()を定義しても、func というnodeタイプが存在しないから何も起こらない。
ですね。

contntent_accessやnode_access?なども調べてみましたが、
これらはいずれもDrupal上のロールをベースに、設定を細分化するもののようです。

社内向けサイトでは、ユーザの所属している組織IDを見てアクセス可否判断を行いたいため、
ロールをベースにしたDrupalのアクセスチェックとは関係の無いチェックをしています。
そのため、そのチェック処理をあたかもuser_access()のように割り込ませて、フック関数内で独自処理により、
TRUE/FALSEを返却すれば、後はDrupalが表示/非表示してくれる。というのが希望なのです。

Drupal的には会社の組織ごとにロールを作成し、ユーザを入れていくという方法の方が合っているのだと思いますが、。
ロールの数が膨大になるし、組織の変更に追従するのは大変なので、完全に外付けロジックとしているのです。

現在、hook関数の一覧を見ています。
おそらく、hook_node_access()などあれば目的に合ってるんじゃないかと思いますが。。
hook_node_access_records()とかありますね、書くときだけでしょうか？
もうちょっと調べて、解決したり何かわかればまた書き込みます。

ありがとうございます。

hook_node_access_records()はレコードの”書き込み時”のみ有効のようでした；

新しい社内システムは既存システムの置き換えを前提としているので、
日本らしい？階層化された組織や”役職”なども認識しないといけないのです。（組織や役職は外部DBから取得します）
そのため、アクセス権のチェック自体は既存モジュールでカバーすることはあきらめて作りこんだ次第です。

Taxonomyやグループは、今作りこんだ仕組みとは別の観点で役に立つかも知れないと思います。
ロール、社内アクセス権以外の、任意の人が集まったグループ等。

現在のところ、hook_nodeapi()でできるところまでするのが最善だと思っています。。
検索時は、$opに"search result"が入ってくるので、その場合にアクセス権チェックにより不可判断したら$nodeの内容を見えなくする。
これにより、コンテンツを直接アクセスした場合と検索結果の表示については、少なくともアクセス権の無いユーザにはタイトルやコンテンツの内容を見せなくすることができる。しかし、viewsや他のモジュールの表示については個別に対応していかなければいけない。。

何か複雑そうで、楽しそうですね 8)

一番シンプルそうな、tac_liteを見てみましたが、

hook_node_grantsで領域を定義しておいて、
hook_node_access_recordsで、ノード単位で領域を割り当てていく仕組みのような気がします。

別途DBが必要な場合はさらに、hook_db_rewrite_sqlを定義する

たぶん、複数のアクセス制限に対応するための仕組みでしょうか・・・
モジュールのインストールなどを行った際に、node_rebuildが呼ばれて、全ての権限テーブルを再構築しているようです

あきらめました；

hook_node_grants()のパラメータは、$accountと$opなのでやろうとしたことはできませんでした。
理想は、
　　hook_node_access($node, $op) で戻り値がTRUE/FALSEのフック関数なんですがありませんね。
hook_nodeapi()は近いけど戻り値を見てくれない。。

っということで、ノードアクセス制御のhookはあきらめて対症療法とすることにしました。
ノードを表示する局面は主に下記があると思います。他にあった場合は、、その時考えますかねえ。
・直接参照（?q=node/$nid）
　hook_nodeapiでつかまえて、アクセス権が無いと判断した場合は”別のページに飛ばす”。
・viewsモジュールで表示する一覧
　views/includes/views.inc 内の render() 内でアクセスチェック関数を呼び出して不許可の場合はデータを消す。
・ナビゲーション
　アクセス権対応のナビゲーションを作る。
　でも、ブックはなかなかわかりにくいですね；

特にviewsの中を直接触るなどできるだけ避けたいところですが、やむなしと思っています。
viewsにもhook関数は用意されているようですが、これまたコレダというものは見つけられていません；
hook_views_api()、hook_views_query_substitutions()、hook_views_data()あたりを試しましたが、
アクセス権チェックを行う必須条件のノードIDが取得できない；；

コメントありがとうございます。
今までひとりで悶々としていたので、こんな細かい話にまでつきあって頂けるなんて感謝の気持ちでいっぱいです。

ご指摘の通り、node_grants()の場合、ユーザごとに組織と結びつけないといけないので大変そうですね。
それと、node_access_records()はなぜか”書き込み時のみ”つかまえられるようです。

現在の社内アクセス権の制御は下記のようなかんじで実装しています。
ノードごとに
　　array(許可する組織,許可する組織,許可する組織...);
というテーブルを作って、アクセスしようとするユーザが条件に合致するかを調べて許可／不許可を判断する。
組織は階層構造になっているため、例えばあるユーザの組織は下記のようになります。
　　soumu-keiri-sanka-madogiwa

ノードについているアクセス権は、こんなかんじです。
　　array("soumu-ikka", "soumu-nika", "soumu-sanka-madogiwa", "eigyou");
そしてアクセス許可／不許可の判断は、ユーザの所属がこの指定の”配下”にあるか？で判断します。

そのため、ユーザがノードに対して持っている権限を固定で管理しようとすると、
　　soumu, soumu-sanka, soumu-sanka-madogiwa
という個別のロールを定義して、全てにこのユーザを所属させないといけなくなってしまうのです。
（＋node_accessモジュールが必要になりそうです）
これを全社員の全所属に対して行うととても大変なことになりそうであります。

handlerを用いれば、もしかするとソースの変更ではなくて追加で対処できるかも知れませんが、
もう、気力がございません；；；；

ogとはOrganic Groupsなんですね、モジュールを見てみました。
その存在を知らなかったです；

Drupal的には（できれば既存）モジュール内でどうにかしたいですが、
組織数は階層構造も意識すると1000くらいにはなりそうです；

ユーザ管理サーバとogの同期を確保する仕組みと、
ノードごとにogをベースにしたアクセス制御の仕組みがあると対処できるかも知れません。
しかしながら、今回は既にアクセス権の設定とユーザデータの取得／判定ロジックを作りこんでいるので、
今回は大掛かりな変更は難しいところです。

このあたり日本の？組織構造とDrupalのアクセス権をうまく整合をとる定番の方法があれば、
使える局面は多いのではないかと思います。
ただ、多くの会社の場合既にユーザ情報DBやサーバを持っていると思うのでそのあたりの連結部分は
作りこみになってしまいそうですが。。

ありがとうございます。

そうなんですよ、実際にアクセスする人が何人いるかは別としてｗ対象ユーザ自体は結構な量になるので、
所属している組織の数も少なくはないのです。

追加であれ、viewsに手を入れる必要がある事を考えるとやはり、hook_node_access($node, $op)のような、
対象ノードに対するアクセス権チェックを行うためのhook関数があったらいいな～と思いますね。

今回はユーザ（姓／名）のような情報は全て外づけで外部のDBから入力しDrupal上には置かないようにしました。
これも、本来ならばDrupalのprofile等を使ってうまくDrupalに取り込むのが本筋だろうと思うのですが、
モジュールの読み込み、設定等を組み合わせないと動作しないため、あきらめたのです。

つまり、全て自製モジュールによる外付け機能にし、hookだけで対処すれば自製モジュールと他のモジュールの関係は
無いため、自製モジュールのつけはずしによる影響も少なくて済むというメリットを優先しました。
また、役職による権限設定などいかにも日本っぽい？条件を設定する必要がある場合など全て自製で無いと怖い
というのもありますね。

いろいろ教えて頂いたり調べたりして勉強になりました。
ありがとうございます。