CMS Bitrixのプリズムによる情報システムのユーザー権利

ムードは哲学的かつ叙情的であるため、CMS Bitrixで権利システムがどのように正しく実装され、どのように実行されるのかを考えるようになりました。



まず、情報システムのユーザーの権利に関するあなたの世界観について。 私の脳の分析部門で、どんなトピックでも感じ始めて、私はそれをうまく体系化し、それを棚に置きたいという願望を持っています(それは一部の教師からの講義にとても欠けていました!)。



この苦痛を伴うプロセスは、独立したエンティティの最小セットの選択から始まります。 どんなエンティティがありますか、別の言い方をすれば、いくつのデータ型がありますか?



3つのタイプのデータ:「オブジェクト」、「オブジェクトの操作」、「操作の権利」。





オブジェクトは、システム内のあらゆる情報源になり得ます。 たとえば、通常のソーシャルネットワークでは、ユーザープロフィール、ユーザーのフォトアルバム、フォトアルバム内の写真、ユーザーのブログ、コミュニティブログ(「グループ」という言葉は別の意味で既に使用されています)、コメント、最後になります。 オブジェクト間で階層関係を構築できます。 オブジェクトを、他のオブジェクトとのやり取りを開始できるアクティブと、このようなことはできず、誰かがやり取りするのを待つだけのパッシブに分けてみましょう。



単純なケースでは、ユーザーアカウントのみをアクティブオブジェクトに関連付けることができますが、チェーンは同じユーザーによって開始された場合でも、別のオブジェクトとしてコミュニティが他のオブジェクトとの対話を開始するようにシステムを構築できます。



たとえば、ユーザーは、コミュニティの所有者として、コミュニティに代わってニュースを公開したいと考えています。 その後、コミュニティは「ニュースブログ」オブジェクトとの対話を開始できます。このオブジェクトの所有者は「管理者」です。 ユーザーは個人のように、コミュニティは合法のように呼び出すことができます。 弁護士の皆さん、こんにちは。 ここで何をどのように取得するかは重要ではありませんが、システムのオブジェクトは、システムの作成者が十分に倒錯したアクティブなオブジェクトになり得ることを理解することが重要です。



しかし、私たちの場合は、情報ユニットとして、ユーザーのみ、またはむしろ彼のアカウントとします。



操作...ああ...はい...つまり、OOP ...はい...このパラダイムのファンはすでに感じています。 これらは、オブジェクトに対して実行できるアクションです。 オブジェクトごとに異なる操作セットがあります。 たとえば、フォトアルバムの視聴、プライバシー設定の編集、写真の追加、コメントの追加ができます。



私たちがブースで楽園に住んでいたなら、それは終わりました。 しかし、私たちは地球上にm **** sで住んでいます。



権利、または操作に対する権利は、アクティブなオブジェクトのみが所有できるデータです。 このデータにより、オブジェクトに対して操作を実行できます。



ただし、最初の2つのオブジェクトとは異なり、「操作権」は動的データとして計算されます。 また、オブジェクトに対する「有効な権利」などの概念もあります。 システムが異なると、計算方法も異なります。 たとえば、管理者によって付与された権利を取得し、+自分がメンバーであるグループの権利と組み合わせ、+階層の上位のオブジェクトに対する権限、+グループの権利、階層の上位のオブジェクト、+所有者の権利を奪いますこのオブジェクトは、あなたとあなたがメンバーになっているグループ、より正確には...禁止するように設定されています。 リストされたオブジェクトのいずれにも権限が設定されていない場合は、デフォルトの権限が用意されています。 Bitrixに渡します。 つまり、そのようなシステムの場合、APIはどのように見えるべきでしょうか?



$perms = GetPerms(active_object_id, passive_object_id, $operation=false);



if(perms['super_mega_permission'])

{



echo 'ALL';



}

else if(perms['write'])

{



echo 'only write :(';



}

etc

{



}








しかし、Bitrixでは、Nyuraおばさんからのあらゆる場面での異種および異種APIの束。 実際、それらは同じではありませんが、開発者は明らかにオカマのカミソリを使用していません。 管理パネルでユーザーを異なるグループに分割する必要がある場合、各モジュールのデフォルトの権限を設定する必要がある場合を理解しています。 登録ユーザーなどのデフォルトグループを設定します。 しかし、なぜこのようなトリッキーなAPIなのでしょうか?



あなたは、データ構造を複雑にしすぎないように言うでしょう。 しかし、私は歯を与えます、あなたの各々は最適な構造を思い付きます。 たぶんそれはBitrixにありますが、なぜそのようなAPIなのでしょうか? Bitrixでは、個々のユーザーにアクセス権を設定することはできず、グループにのみアクセス権を設定できることを念頭に置いておくと、それらは著しくキャッシュされます。



結論として、APIの例を示します。



string CBlog::GetBlogUserCommentPerms( int ID, int userID );



string CBlog::GetBlogUserPostPerms ( int ID, int userID );



string GetBlogUserPostPerms::GetBlogUserCommentPerms( int ID, int userID );



string GetBlogUserPostPerms::GetBlogUserPostPerms ( int ID, int userID );



bool CSocNetUserPerms::CanPerformOperation( int fromUserID, int toUserID, string operation, bool bCurrentUserIsAdmin = false );



array CSocNetUserPerms::InitUserPerms( int currentUserID, int userID, bool bCurrentUserIsAdmin );



mixed CSocNetFeaturesPerms::CanPerformOperation( int userID, char type, mixed id, string feature, string operation, bool bUserIsAdmin = false );



bool CSocNetFeaturesPerms::CurrentUserCanPerformOperation( char type, int id, string feature, string operation );



CForumNew::GetUserPermission ().









私が限界から遠く離れているかどうかはわかりませんが、私はそのように思っています。



All Articles