S2Buriでユーザ権限ごとにアクセス制御(3)

seasar

この仕様の方が良いですね。データのID云々の所は後からの追加だったので思いつきませんでした。
仕様としてデータのIDがあってもRoleを見るように修正します
comment by id:makotan

ありがとうございます。

ただこの方針で行くと、もう一点修正しておかないといけないところがありそうです。

この方針の主眼は「実行ユーザがそのActivityを実行してもよいかどうかのチェックを常に行う」ということかと思います。少なくとも自分の中ではそうです。
単純にいえばActivityが乗っているレーンのロールに対応づけられた実行ユーザじゃなきゃそのActivityは実行できないんですよ、と一言で説明できると、XPDLによる設定がやりやすいと思うのですね。（あ、これTWE2.x系の表示イメージで書いてます。）

昨日のエントリの修正でそれが実現できたかな？と思ってたんですが、実はまだチェックがかからないルートがあるのです。
昨日の最後に気がついてさっき試していたところなんですが、どうもACTIVITYアノテーションで明示的にActivityを指定した場合はそもそもburi2.diconのBuriWorkFlowsUtilに入っていかないみたいですね。いきなり buri2.xpdlのBuriEngineプロセスの方に入っていっちゃう。つまり、Participantによる権限チェックが働かない。

今までの設計だと、実行するActivityを1つに特定するためにどうしようかという観点で、Participantを条件にして絞り込んでみようか、みたいな扱いだったと思われます。
その流れだと、Activityが指定されているのだからActivitySelectRuleでActivityを探しにいく必要がないというのは一貫していると思います。

ただ私がやりたい「常に実行権限をチェックする」という方針でいくと、困ってしまうわけです。

ACTIVITYアノテーションを使わないようにXPDLとBAOを設計して回避することもできそうですが、その辺りに色々隠し制約があるとハマることが多そうな気がするので、前述の仕様に統一するのなら、ACTIVITYアノテーションを指定した場合でも実行ユーザがそのActivityを実行してもよいかどうかのチェックが働くようになって欲しいなぁと。

逆にParticipantによるチェックがいらないフローなら、NoCheckParticipantProviderImplみたいな実装クラスを使えばParticipantにかかわらず常にOKという流れも簡単に実現できそうですし。性能的にはチェック自体を行わない処理系よりも不利ですけどね。

なんて感じでできそうかどうか、もうちょっと見てみます。