パーソナルツール
現在の場所: ホーム zope 2.8 + plone 2.1 新機能一覧 #16: Local roles blacklisting
書いた本
Plone 完全活用ガイド の Chapter 1, 2, 3, 11 を執筆しました。
plone のインストール、使い方から、機能・デザインのカスタマイズ、プロダクトの作り方まで、 plone のすべてがぎゅっと詰まっている書籍になっていると思います。
plone に興味がある人から、すでに使いこなしている方まで、ぜひ読んでみてください。
Plone 完全活用ガイドのサポートページ
ナビゲーション

 
文書操作

#16: Local roles blacklisting

作成者 takanori 最終変更日時 2008年06月04日 12時41分

Plone needs the ability to remove access rights from people that have been given permissions higher up in the hierarchy

http://plone.org/products/plone/roadmap/16

Motivation

動機づけ

The current local-roles implementation in Zope makes it impossible to reduce the rights given to users

Zopeの現在のローカル役割実施は、ユーザーに与えられる権利を減らすことを不可能にします

when you go deeper in folder hierarchy since roles, once given to a user, cannot be taken away from a user. Therefore it is impossible to have a really flexible and moreover easy-to-use way of dealing with security. An ideal situation would be that you are able to provide access to your site-root to everybody by giving the whole group the proper role and when you go deeper in the structure, you start restricting access by redefining the local-roles in that context. Right now, you can't really do that without using tricks with workflows and even then it is very limited and very confusing and counter-intuitive.

あなたがフォルダでより深くなるとき、一旦ユーザーに与えられるならば、役割から階層はユーザーから取られることができません。したがって、安心してカードを配る本当に柔軟でさらに使いやすい方法を持つことは、不可能です。理想的な状況はあなたが全グループに適当な役割を与えることによって誰にでもあなたのサイト-根への接近を提供することができるということです、そして、あなたが建造物でより深くなるとき、あなたはその前後関係でのローカル役割を再定義することによってアクセスを制限し始めます。たった今、あなたは仕事の流れでトリックを使用することなく本当にそうすることができません、そして、それでも、それは非常に制限されて非常に混乱させて直観に反しています。

Even when PLIP7 is fully functional, you still can't restrict access to certain folders inside GroupFolders for users that have access to the GroupFolder itself. You can think: why would you do that? Well, there are numerous situations where you want this. Of course you can define a workflow-state that give permissions to certain roles but once you have given a user this role and you want to further restrict his access to subfolders, the only thing you can do is to create a new role and a new workflow-state, a new role that the user doesn't have already. But this only postpones the problem to a folder level deeper. This PLIP describes the solution and would make live a lot easier.

PLIP7 が完全には機能的なときでも、あなたはGroupFolderにアクセスするユーザーのためにGroupFoldersの中にまだアクセスを特定のフォルダに制限することができません。あなたは考えることができます:なぜ、あなたはそうするでしょうか?さて、あなたがこれを望む多数の状況が、あります。もちろん、あなたは特定の役割に許可を与える仕事の流れ-州を定めることができます、しかし、あなたがユーザーにこの役割を与えた、そして、一旦あなたがさらに彼のアクセスをサブフォルダに制限したいならば、あなたがすることができる唯一のものは新しい役割と新しい仕事の流れ-州(ユーザーがすでに持たない新しい役割)をつくることになっています。しかし、これはより深く問題をフォルダレベルに延期するだけです。このPLIPは解決を記述して、ライブをだいぶより簡単にします。

Proposal

提案

The proposol for this PLIP is to enhance the way GRUF checks for local-roles in such a way that before it traverses up

このPLIPのためのproposolは、GRUFがそれの前の上で横断するそのような方向でのローカル役割について調べる方法を強化することです

the folder hierarchy, it checks if the current folder is set to acquire local-roles from parents or not. This check is done for every parent it finds on its way up the tree.

フォルダ階層、それは現在のフォルダが両親からローカル役割を得る用意が整っているかどうか調べます。このチェックは、それが木の上で途中で発見するあらゆる親のためにされます。

Implementation

実施

Implementing looks quite simpel and I have done some tests that have been very promising. At first, in the Sharing page

インプリメントすることは非常にsimpelに見えます、そして、私は非常に有望だったいくらかのテストをしました。最初で、Sharingページで、

in Plone a check-box is added where the user with proper permissions can check if he wants to acquire the local-roles from parent folders or not. The selection is then stored as a property on the folder/object.

適当な許可をもつユーザーが彼が親のようなフォルダからローカル役割を得たいかどうか調べることができる所で、Ploneで、チェックボックスは加えられます。選択は、それからフォルダ/物の上に資産として保存されます。

The next step would be to alter the function in GRUF that returns the local-roles in a given context. As far as I can see this happens in GRUFUser.py in the function getRolesInContext. Inside that function is a simple loop that does the traversal. In this loop a check needs to be done on the current object to see if it has set the property for acquisition or not. If set to false, the loop will stop.

次のステップは、与えられた前後関係でのローカル役割を返すGRUFで、機能を変えることになっています。私がわかることができる限り、これは機能 getRolesInContextでGRUFUser.pyで起こります。機能する内部は、横断をする単純なループです。このループでは、チェックはそれがプロパティを獲得に設定したかどうか見るために現在の物の上でされる必要があります。偽にセットされるならば、ループは止まります。

As I said, I did some tests and it seemed to work. I did encounter a problem that I couldn't fix and it seemed at that time only remotely related to this but I'm not sure exactly what this problem was back then (sorry). I expect that when enough skilled people take a look at this, this can be fixed. And like I said, the idea is simple but the implications are huge and could make our lives sooo much easier.

私が言ったように、私はいくらかのテストをしました、そして、それは働くようでした。私は私が固定することができなかった問題に遭遇しました、そして、それは離れてその時これに関連があるようなだけでした、しかし、私はこの問題がそうであった必ずしもことがそれから後退する(残念に思う)と確信しません。私は、十分な熟練した人々がこれを見てみるとき、これが固定されることができると思っています。そして、私が言ったように、考えは単純です、しかし、含みは巨大で、我々の命soooを非常により簡単にすることができました。


Powered by vine linux, python, zope, plone, coreblog