ParserRowPolicyNames ثلاث صيغ للتجميع (وليس حاصل ضرب ديكارتي كامل):
- أسماء متعددة، هدف واحد — ينشئ
pol1, pol2 ON table1كل اسم مُدرج على ذلك الجدول وحده (أوdb.*). - اسم واحد، أهداف متعددة — ينشئ
pol1 ON table1, table2الاسم المختصر نفسه على كل هدف مُدرج. - أزواج مختلطة — ينشئ
p1 ON t1, p2 ON t2كل اسم على هدفه المقترن به فقط.
ON متعددة الجداول ضمن مجموعة واحدة: يُرفض p1, p2 ON t1, t2. وبعد مجموعة بأسماء متعددة، لا يمكنك أيضًا إلحاق مجموعة أخرى من name ON target مفصولة بفواصل ضمن العبارة نفسها.
ينطبق ON CLUSTER الاختياري على العبارة بأكملها (اسم عنقود واحد). لا يقبل ClickHouse ON CLUSTER مختلفًا لكل اسم سياسة مُجمّع ضمن عملية إنشاء واحدة — نفّذ عبارات CREATE ROW POLICY منفصلة عندما يلزم إنشاء سياسات على عناقيد مختلفة.
تتطلب CREATE ROW POLICY صلاحية CREATE ROW POLICY على الجدول الذي تُنشأ عليه السياسة. أما OR REPLACE فتتخلص من سياسة قائمة تحمل الاسم نفسه، بما في ذلك الأدوار التي تنطبق عليها، ولذلك تتطلب أيضًا صلاحية DROP ROW POLICY على ذلك الجدول. وصلاحية DROP ROW POLICY مطلوبة سواء أكانت السياسة موجودة مسبقًا أم لا، لذا لا يمكن استخدام العبارة لمعرفة السياسات الموجودة.
أسماء وجداول متعددة
صحيح:عبارة USING
تُحدِّد شرط تصفية لجدول ما، بحيث لا يرى المستخدم إلا الصفوف التي يتحقق فيها الشرط (أي التي يُقيَّم فيها إلى قيمة غير صفرية). ويُشبه ذلك إضافة شرطWHERE إضافي إلى كل استعلام يُنفّذه المستخدم على هذا الجدول.
على سبيل المثال، تقصر السياسة التالية وصول analyst_role على الصفوف الخاصة بالاتحاد الأوروبي:
SELECT * FROM db.orders الصفوف نفسها التي كان سيُعيدها الاستعلام SELECT * FROM db.orders WHERE region = 'EU'.
عبارة TO
في قسمTO، يمكنك تحديد قائمة بالمستخدمين والأدوار التي تنطبق عليها هذه السياسة. على سبيل المثال، CREATE ROW POLICY ... TO accountant, john@localhost.
تعني الكلمة المفتاحية ALL جميع مستخدمي ClickHouse، بما في ذلك المستخدم الحالي. وتتيح الكلمة المفتاحية ALL EXCEPT استبعاد بعض المستخدمين من قائمة جميع المستخدمين، على سبيل المثال، CREATE ROW POLICY ... TO ALL EXCEPT accountant, john@localhost
تتم مطابقة الأدوار المذكورة في قسم TO، بما في ذلك تلك الواردة بعد ALL EXCEPT، مع الأدوار المفعّلة للمستخدم الحالي (system.enabled_roles)، وليس مع كل دور مُمنَح للمستخدم، لذا يمكن أن يغيّر SET ROLE السياسات التي تنطبق.
عبارة AS
يُسمح بتفعيل أكثر من سياسة واحدة على الجدول نفسه للمستخدم نفسه في الوقت ذاته. لذلك نحتاج إلى طريقة لدمج الشروط الواردة من سياسات متعددة. افتراضيًا، تُدمَج السياسات باستخدام العامل المنطقيOR. على سبيل المثال، السياسات التالية:
peter من رؤية الصفوف التي يكون فيها إما b=1 أو c=2.
تحدِّد عبارة AS كيفية دمج السياسات مع السياسات الأخرى. ويمكن أن تكون السياسات إما متساهلة أو مقيِّدة. وبشكل افتراضي، تكون السياسات متساهلة، ما يعني أنها تُدمج باستخدام العامل المنطقي OR.
ويمكن بدلاً من ذلك تعريف السياسة على أنها مقيِّدة. وتُدمج السياسات المقيِّدة باستخدام العامل المنطقي AND.
إليك الصيغة العامة:
access_control_improvements.users_without_row_policies_can_read_rows مفعَّل افتراضيًا. وبالتالي فإن المستخدم الذي لا ينطبق عليه أي شرط يرى كل صف، أما access_control_improvements.throw_on_unmatched_row_policies، المعطَّل افتراضيًا، فيثير استثناءً بدلاً من ذلك عندما تكون للجدول شروط ولا ينطبق أي منها.
على سبيل المثال، السياسات التالية:
peter برؤية الصفوف فقط إذا كان الشرطان b=1 AND c=2 متحققَين.
تُدمَج سياسات قاعدة البيانات مع سياسات الجدول.
على سبيل المثال، السياسات التالية:
peter رؤية صفوف table1 فقط إذا تحقّق الشرطان b=1 AND c=2 معًا، رغم أن أي جدول آخر في mydb لن تُطبَّق عليه للمستخدم سوى سياسة b=1.
الجداول التي تقرأ من جداول أخرى
تُصفّي سياسة الصفوف البيانات عند قراءتها فعليًا. يُرجع جدولAlias صفوف جدول الهدف كما لو كانت صفوفه، لذا تنطبق سياسات صفوف جدول الهدف على القراءة عبر الاسم البديل أيضًا، إلى جانب سياسات جدول Alias نفسه، مع الجمع بينها بالعامل المنطقي AND. ويطبّق جدول Merge سياسات الجداول التي يقرأ منها. لكن ثمة استثناء: إذا كان أحد الجداول المطابقة يقرأ من خادم بعيد، مثل جدول Distributed، فإن الخادم البعيد يعالج الاستعلام قبل تطبيق السياسة، لأنها تُطبَّق بعد القراءة من ذلك الجدول، لا أثناءها. وقد يفشل الاستعلام إذا أجرى تجميعًا دون اختيار الأعمدة التي تعتمد عليها السياسة، أو يُرجع صفوفًا أقل مما تسمح به السياسة إذا طبّق الخادم البعيد ORDER BY ... LIMIT على صفوف كانت السياسة ستُخفيها. لذا، عرّف السياسة على الجداول المحلية الأساسية في كل خادم بعيد.
ولا ينطبق ذلك على كل جدول يقرأ من جدول آخر. فجدول Buffer والعرض المُجسَّد اللذان يقرآن عبر جدول الوجهة أو جدول الهدف لا يرثان سياسات صفوف ذلك الجدول: فالسياسة تُكتب وفق مخطط جدول الهدف، وفي حالة العرض الذي يستخدم SQL SECURITY DEFINER، تُقيَّم لمستخدم غير المستخدم الذي ينفّذ القراءة. في هذه الحالات، عرّف السياسة على الجدول الذي يستعلم منه المستخدمون فعليًا.
جداول Distributed والجداول المعتمدة على خوادم بعيدة
تُصفّي سياسة الصفوف الصفوف في الموضع الذي تُقرأ فيه بيانات الجدول فعليًا. فالجدول الذي يفوّض القراءة إلى خوادم بعيدة، مثل جدول Distributed أو طبقة تغليف فوقه (مثل عرض مادي له هدفDistributed)، لا يرسل إلى الخوادم البعيدة سوى نص الاستعلام، ولا يمكنه تطبيق عامل تصفية السياسة على القراءة البعيدة. ولمنع إسقاط عامل التصفية بصمت، تُرفض الاستعلامات الموجّهة إلى هذه الجداول من المستخدمين الذين تنطبق عليهم السياسة، ويظهر الخطأ ILLEGAL_PREWHERE.
بدلًا من ذلك، عرّف السياسة على الجداول المحلية الأساسية في كل خادم بعيد؛ إذ تُطبّق هناك عند قراءة الاستعلام المُرسَل لها:
جداول Join
جدول Join هو جدول تجزئة مُعدّ مسبقًا تقرؤه عملياتJOIN أو joinGet كما هو، ولذلك يتعذّر تصفية صفوفه أثناءها. وتؤدي السياسة المطبّقة على جدول كهذا، بما في ذلك سياسة ON db.* الشاملة لقاعدة البيانات بأكملها، إلى تصفية نتائج استعلام SELECT العادي من الجدول، لكن ما دامت هذه السياسة سارية، فإن استعلامات JOIN وjoinGet على هذا الجدول تفشل بالخطأ ACCESS_DENIED.
عبارة ON CLUSTER
تسمح بإنشاء سياسات الصفوف على مستوى العنقود، راجع DDL الموزع. وهذه أيضًا طريقة ملائمة لإنشاء السياسة على الجداول المحلية لكل خادم في العنقود.أمثلة
CREATE ROW POLICY filter1 ON mydb.mytable USING a<1000 TO accountant, john@localhost
CREATE ROW POLICY filter2 ON mydb.mytable USING a<1000 AND b=5 TO ALL EXCEPT mira
CREATE ROW POLICY filter3 ON mydb.mytable USING 1 TO admin
CREATE ROW POLICY filter4 ON mydb.* USING 1 TO admin