CREATE USER

ينشئ حسابات المستخدمين. الصيغة:

CREATE USER [IF NOT EXISTS | OR REPLACE] name1 [, name2 [,...]] [ON CLUSTER cluster_name]
    [{VALID UNTIL datetime | VALID FOR interval}]
    [NOT IDENTIFIED | IDENTIFIED {[WITH {plaintext_password | sha256_password | sha256_hash | double_sha1_password | double_sha1_hash}] BY {'password' | 'hash'}} | WITH NO_PASSWORD | {WITH ldap SERVER 'server_name'} | {WITH kerberos [REALM 'realm']} | {WITH ssl_certificate CN 'common_name' | SAN 'TYPE:subject_alt_name'} | {WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa|...'} | {WITH http SERVER 'server_name' [SCHEME 'Basic']} [{VALID UNTIL datetime | VALID FOR interval}] [GRANTS (privilege ON object [,...])]
    [, {[{plaintext_password | sha256_password | sha256_hash | ...}] BY {'password' | 'hash'}} | {ldap SERVER 'server_name'} | {...} | ... [,...]]]
    [HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
    [IN access_storage_type]
    [ROLE role [,...]]
    [DEFAULT ROLE role [,...]]
    [DEFAULT DATABASE database | NONE]
    [GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
    [SETTINGS variable [= value] [MIN [=] min_value] [MAX [=] max_value] [READONLY | WRITABLE] | PROFILE 'profile_name'] [,...]

تسمح عبارة ON CLUSTER بإنشاء المستخدمين في العنقود، راجع DDL الموزّع.

تحديد الهوية

هناك عدة طرق لتحديد هوية المستخدم:

IDENTIFIED WITH no_password
IDENTIFIED WITH plaintext_password BY 'qwerty'
IDENTIFIED WITH sha256_password BY 'qwerty' or IDENTIFIED BY 'password'
IDENTIFIED WITH sha256_hash BY 'hash' or IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'
IDENTIFIED WITH double_sha1_password BY 'qwerty'
IDENTIFIED WITH double_sha1_hash BY 'hash'
IDENTIFIED WITH bcrypt_password BY 'qwerty'
IDENTIFIED WITH bcrypt_hash BY 'hash'
IDENTIFIED WITH ldap SERVER 'server_name'
IDENTIFIED WITH kerberos or IDENTIFIED WITH kerberos REALM 'realm'
IDENTIFIED WITH ssl_certificate CN 'mysite.com:user'
IDENTIFIED WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa', KEY 'another_public_key' TYPE 'ssh-ed25519'
IDENTIFIED WITH http SERVER 'http_server' or IDENTIFIED WITH http SERVER 'http_server' SCHEME 'basic'
IDENTIFIED BY 'qwerty'

يمكن تعديل متطلبات تعقيد كلمة المرور في config.xml. فيما يلي مثال على تهيئة تشترط أن تتكون كلمات المرور من 12 حرفًا على الأقل وأن تحتوي على رقم واحد. وتتطلب كل قاعدة من قواعد تعقيد كلمة المرور تعبيرًا نمطيًا لمطابقة كلمات المرور، بالإضافة إلى وصف للقاعدة نفسها.

<clickhouse>
    <password_complexity>
        <rule>
            <pattern>.{12}</pattern>
            <message>be at least 12 characters long</message>
        </rule>
        <rule>
            <pattern>\p{N}</pattern>
            <message>contain at least 1 numeric character</message>
        </rule>
    </password_complexity>
</clickhouse>

في ClickHouse Cloud، يجب أن تستوفي كلمات المرور، افتراضيًا، متطلبات التعقيد التالية:

أن تتكون من 12 محرفًا على الأقل
أن تحتوي على رقم واحد على الأقل
أن تحتوي على حرف كبير واحد على الأقل
أن تحتوي على حرف صغير واحد على الأقل
أن تحتوي على رمز خاص واحد على الأقل

أمثلة

اسم الـ username التالي هو name1 ولا يتطلب كلمة مرور، وهو ما لا يوفر بطبيعة الحال قدرًا كبيرًا من الأمان:
CREATE USER name1 NOT IDENTIFIED

لتحديد كلمة مرور بنص واضح:

CREATE USER name2 IDENTIFIED WITH plaintext_password BY 'my_password'

تُخزَّن كلمة المرور في ملف نصي لـ SQL داخل /var/lib/clickhouse/access، لذا فليس من الجيد استخدام plaintext_password. جرّب sha256_password بدلًا من ذلك، كما هو موضح تاليًا…

الخيار الأكثر شيوعًا هو استخدام كلمة مرور مُجزّأة باستخدام SHA-256. سيتولى ClickHouse تجزئة كلمة المرور نيابةً عنك عند تحديد IDENTIFIED WITH sha256_password. على سبيل المثال:
CREATE USER name3 IDENTIFIED WITH sha256_password BY 'my_password'
يمكن للمستخدم name3 الآن تسجيل الدخول باستخدام my_password، لكن كلمة المرور تُخزَّن على هيئة قيمة التجزئة المذكورة أعلاه. ويُنشأ ملف SQL التالي في /var/lib/clickhouse/access ويُنفَّذ عند بدء تشغيل الخادم:
/var/lib/clickhouse/access $ cat 3843f510-6ebd-a52d-72ac-e021686d8a93.sql ATTACH USER name3 IDENTIFIED WITH sha256_hash BY '0C268556C1680BEF0640AAC1E7187566704208398DA31F03D18C74F5C5BE5053' SALT '4FB16307F5E10048196966DD7E6876AE53DE6A1D1F625488482C75F14A5097C7';

إذا كنت قد أنشأت بالفعل قيمة hash وقيمة salt المقابلة لـ username، فيمكنك استخدام IDENTIFIED WITH sha256_hash BY 'hash' أو IDENTIFIED WITH sha256_hash BY 'hash' SALT 'salt'. وعند التعريف باستخدام sha256_hash مع SALT، يجب حساب hash من concatenation بين ‘password’ و’salt’.

لا تكون double_sha1_password مطلوبة عادةً، لكنها تكون مفيدة عند العمل مع العملاء الذين يتطلبونها (مثل MySQL interface):
CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password'
يُنشئ ClickHouse الاستعلام التالي ويشغّله:
CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518'
يُعد bcrypt_password الخيار الأكثر أمانًا لتخزين كلمات المرور. فهو يستخدم خوارزمية bcrypt، وهي مقاومة لهجمات القوة الغاشمة حتى إذا أصبحت قيمة تجزئة كلمة المرور compromised.
CREATE USER name5 IDENTIFIED WITH bcrypt_password BY 'my_password'
يقتصر طول كلمة المرور في هذه الطريقة على 72 حرفًا. كما يمكن تعديل معلمة عامل العمل الخاصة بـ bcrypt، التي تحدد مقدار العمليات الحسابية والوقت اللازمين لحساب التجزئة والتحقق من كلمة المرور، في إعدادات الخادم:
<bcrypt_workfactor>12</bcrypt_workfactor>
يجب أن تكون قيمة عامل العمل بين 4 و31، والقيمة الافتراضية هي 12.

بالنسبة إلى التطبيقات ذات المصادقة عالية التكرار، فكّر في استخدام طرق مصادقة بديلة بسبب الحمل الحسابي الإضافي لـ bcrypt عند ارتفاع قيم عامل العمل.

يمكن أيضًا حذف نوع كلمة المرور:
CREATE USER name6 IDENTIFIED BY 'my_password'
في هذه الحالة، سيستخدم ClickHouse نوع كلمة المرور الافتراضي المحدد في إعدادات الخادم:
<default_password_type>sha256_password</default_password_type>
أنواع كلمات المرور المتاحة هي: plaintext_password, sha256_password, double_sha1_password.

يمكن تحديد عدة طرق مصادقة:

CREATE USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3''

ملاحظات:

قد لا تدعم الإصدارات الأقدم من ClickHouse صيغة تعدد طرق المصادقة. لذلك، إذا كان خادم ClickHouse يحتوي على مستخدمين من هذا النوع ثم جرى الرجوع به إلى إصدار لا يدعم ذلك، فسيصبح هؤلاء المستخدمون غير قابلين للاستخدام وستتعطل بعض العمليات المرتبطة بالمستخدمين. ولإجراء الرجوع إلى إصدار أقدم بسلاسة، يجب ضبط جميع المستخدمين بحيث تكون لكل منهم طريقة مصادقة واحدة فقط قبل الرجوع إلى إصدار أقدم. وبدلاً من ذلك، إذا جرى الرجوع بالخادم إلى إصدار أقدم من دون اتباع الإجراء الصحيح، فيجب حذف المستخدمين المتأثرين.
لا يمكن أن يتعايش no_password مع طرق مصادقة أخرى لأسباب أمنية. لذلك، لا يمكنك تحديد no_password إلا إذا كانت طريقة المصادقة الوحيدة في الاستعلام.

مضيف المستخدم

مضيف المستخدم هو المضيف الذي يمكن إنشاء اتصال منه بـ خادم ClickHouse. ويمكن تحديد المضيف في قسم HOST من الاستعلام بالطرق التالية:

HOST IP 'ip_address_or_subnetwork' — لا يمكن للمستخدم الاتصال بـ خادم ClickHouse إلا من عنوان IP المحدد أو من شبكة فرعية. أمثلة: HOST IP '192.168.0.0/16'، HOST IP '2001:DB8::/32'. للاستخدام في production، حدِّد عناصر HOST IP فقط (عناوين IP وأقنعتها)، لأن استخدام host وhost_regexp قد يسبب latency إضافيًا.
HOST ANY — يمكن للمستخدم الاتصال من أي موقع. وهذا هو الخيار الافتراضي.
HOST LOCAL — لا يمكن للمستخدم الاتصال إلا محليًا.
HOST NAME 'fqdn' — يمكن تحديد مضيف المستخدم بصيغة FQDN. على سبيل المثال، HOST NAME 'mysite.com'.
HOST REGEXP 'regexp' — يمكنك استخدام التعبيرات النمطية pcre عند تحديد مضيفات المستخدمين. على سبيل المثال، HOST REGEXP '.*\.mysite\.com'.
HOST LIKE 'template' — يتيح لك استخدام المعامل LIKE لتطبيق filter على مضيفات المستخدمين. على سبيل المثال، HOST LIKE '%' يكافئ HOST ANY، بينما يقوم HOST LIKE '%.mysite.com' بتصفية جميع المضيفات ضمن النطاق mysite.com.

هناك طريقة أخرى لتحديد المضيف، وهي استخدام صياغة @ بعد username. أمثلة:

CREATE USER mira@'127.0.0.1' — يكافئ صياغة HOST IP.
CREATE USER mira@'localhost' — يكافئ صياغة HOST LOCAL.
CREATE USER mira@'192.168.%.%' — يكافئ صياغة HOST LIKE.

يتعامل ClickHouse مع user_name@'address' باعتباره username كاملًا. لذلك، من الناحية التقنية، يمكنك إنشاء عدة مستخدمين لهم نفس user_name مع تراكيب مختلفة بعد @. ومع ذلك، لا نوصي بذلك.

عبارة VALID UNTIL

تتيح تحديد تاريخ انتهاء صلاحية طريقة مصادقة ووقته اختياريًا. تقبل سلسلة نصية كمعلَمة. يُوصى باستخدام تنسيق YYYY-MM-DD [hh:mm:ss] [timezone] للتاريخ والوقت، حيث يجب أن تكون [timezone] إزاحة رقمية مثل +09:00 أو إحدى القيم UTC أو GMT أو Z أو MSK أو MSD؛ ولا يتم التعرّف على مناطق IANA الزمنية المسمّاة مثل Asia/Tokyo (انظر الملاحظة أدناه). افتراضيًا، تساوي هذه المعلَمة 'infinity'. يتراوح الموعد النهائي المقبول من 1900-01-01 00:00:00 UTC إلى 9999-12-31 09:59:59 UTC — وهي أحدث لحظة تظل ضمن السنة 9999 في كل منطقة زمنية، لذا لا تُقيَّد اللحظة المخزنة عند عرضها. يعني الموعد النهائي الماضي أن بيانات الاعتماد منتهية الصلاحية بالفعل. لا تُقبل المواعيد النهائية السابقة لـ 1970-01-01 00:00:01 UTC إلا كوسم «منتهي الصلاحية بالفعل»: إذ تُحوَّل إلى التمثيل القياسي لأقدم لحظة منتهية الصلاحية، أي بعد ثانية واحدة من حقبة Unix (1970-01-01 00:00:01)، لذا يعرض SHOW CREATE USER تلك اللحظة بدلًا من الموعد النهائي الذي كتبته. أما المواعيد النهائية بدءًا من تلك اللحظة فتُخزَّن كما هي تمامًا. يُخزَّن الموعد النهائي كلحظة مطلقة، لكن SHOW CREATE USER وsystem.users يعرضانه وفق المنطقة الزمنية للخادم أو الجلسة، لذا تظهر اللحظة المخزنة نفسها كنص وقت محلي مختلف على الخوادم ذات التهيئات المختلفة: فعلى سبيل المثال، تُعرض اللحظة المنتهية الصلاحية والمحوَّلة إلى التمثيل القياسي أعلاه كـ 1970-01-01 00:00:01 على خادم في UTC وكـ 1970-01-01 14:00:01 على خادم في Pacific/Kiritimati. يعتمد فرض القيود دائمًا على اللحظة المخزنة، وليس على طريقة عرضها. يحدد موضع العبارة طرق المصادقة التي تنطبق عليها:

قبل عبارة IDENTIFIED (أو عندما لا يحدد الاستعلام أي طريقة مصادقة على الإطلاق): يكون الموعد النهائي على مستوى المستخدم وينطبق على جميع طرق مصادقة المستخدم.
بعد طريقة مصادقة: ينطبق الموعد النهائي على تلك الطريقة فقط. لذلك، فإن العبارة المكتوبة بعد قائمة IDENTIFIED كاملة ترتبط بالطريقة الأخيرة فقط، وتبقى الطرق السابقة دون انتهاء صلاحية.

أمثلة:

CREATE USER name1 VALID UNTIL '2025-01-01'
CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'
CREATE USER name1 VALID UNTIL '2025-01-01 12:00:00 +09:00'
CREATE USER name1 VALID UNTIL 'infinity'
CREATE USER name1 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2' — ينطبق الموعد النهائي على مستوى المستخدم على كلتا الطريقتين.
CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01' — ينطبق الموعد النهائي على طريقة bcrypt_password فقط؛ ولا تنتهي صلاحية plaintext_password أبدًا.

تُحلَّل سلسلة التاريخ والوقت بواسطة parseDateTimeBestEffort، التي لا تتعرّف إلا على رموز المناطق الزمنية UTC وGMT وZ وMSK وMSD، والإزاحات الرقمية مثل +09:00 أو -05:00. لا تُدعم مناطق IANA الزمنية المسمّاة مثل Asia/Tokyo أو Europe/London، كما أن الإزاحة الثابتة ليست مكافئة لمنطقة IANA في المناطق التي تتبع التوقيت الصيفي، لذا يجب حساب الإزاحة الصحيحة للتاريخ المحدد الذي تُرمِّزه.

عبارة VALID FOR

تُعد عبارة VALID FOR اختصارًا ملائمًا لعبارة VALID UNTIL. فبدلًا من تاريخ ووقت مطلقين، تقبل فاصلًا زمنيًا، ويُحتسب الموعد النهائي لانتهاء الصلاحية بإضافة ذلك الفاصل الزمني إلى الوقت الحالي عند تنفيذ الاستعلام. ثم تُخزَّن النتيجة بصيغة VALID UNTIL، لذا يعرض SHOW CREATE USER دائمًا الموعد النهائي المطلق بعد حسمه. يمكن استخدامها في كل موضع يمكن استخدام VALID UNTIL فيه، وتتبع قواعد الترتيب نفسها: قبل IDENTIFIED (أو عند عدم تحديد طريقة مصادقة) تمثل موعدًا نهائيًا على مستوى المستخدم ينطبق على جميع الطرق، بينما إذا جاءت بعد طريقة مصادقة فإنها تنطبق على تلك الطريقة فقط. يُخزَّن الموعد النهائي ويُطبَّق بدقة الثواني، لذلك تُرفض الفواصل الزمنية التي تقل عن ثانية (NANOSECOND وMICROSECOND وMILLISECOND)؛ وأصغر وحدة مقبولة هي SECOND. يُقبل الفاصل الزمني السالب كوسيلة لاعتبار بيانات الاعتماد منتهية الصلاحية بالفعل؛ وإذا وقع الموعد النهائي الناتج قبل 1970-01-01 00:00:01 UTC، فيُحوَّل إلى تلك اللحظة الأدنى المنتهية الصلاحية، وهي التي يعرضها SHOW CREATE USER لاحقًا — وفق المنطقة الزمنية للخادم أو الجلسة، كما هو موضح في VALID UNTIL. أمثلة:

CREATE USER name1 VALID FOR INTERVAL 1 DAY
CREATE USER name1 VALID FOR INTERVAL 3 MONTH
CREATE USER name1 VALID FOR INTERVAL 1 DAY + INTERVAL 12 HOUR
CREATE USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2' — ينطبق الموعد النهائي على مستوى المستخدم على كلتا الطريقتين.
CREATE USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY — ينطبق الموعد النهائي على طريقة bcrypt_password فقط؛ ولا تنتهي صلاحية plaintext_password أبدًا.

عبارة GRANTS

تتيح لك تقييد حقوق الوصول المتاحة لجلسة تمت مصادقتها باستخدام طريقة مصادقة محددة. وتقبل قائمة بالامتيازات، بين قوسين، بالصيغة نفسها المستخدمة في عبارة GRANT. تُحدَّد العبارة بعد طريقة المصادقة (وبعد عبارة VALID UNTIL الخاصة بها، إن وُجدت)، ولا تنطبق إلا على تلك الطريقة. عندما يسجّل مستخدم الدخول باستخدام طريقة مصادقة كهذه، تكون حقوق وصول الجلسة هي تقاطع حقوق وصول المستخدم (بما فيها الحقوق الناتجة عن الأدوار الممنوحة) والامتيازات المدرجة في العبارة. ولا تضيف العبارة أي حقوق وصول مطلقًا: فإذا لم يكن امتياز مدرج ممنوحًا للمستخدم، فلن تمتلكه الجلسة. كذلك، لا تستطيع الجلسات التي تمت مصادقتها بهذه الطريقة منح امتيازات (إذ لا يبقى GRANT OPTION بعد التقاطع) أو إدارة الأدوار. ولا تقتصر إدارة الأدوار على إنشائها وتعديلها وحذفها ومنحها وسحبها، بل تشمل أيضًا تغيير الأدوار المفعّلة افتراضيًا للمستخدم (SET DEFAULT ROLE وALTER USER ... DEFAULT ROLE)، وهو أمر مرفوض أيضًا. تبدّل EXECUTE AS الكيان الأساسي للجلسة، لذا تقتصر العبارة التي تعمل بانتحال الهوية على تقاطع حقوق وصول المستخدم الهدف والامتيازات المدرجة، بدلًا من حقوق المستخدم الذي سجّل الدخول. ولا يُرفع القيد نفسه مطلقًا، ويتطلب انتحال الهوية أن يكون IMPERSONATE ON target ممنوحًا للمستخدم ومدرجًا في العبارة في آنٍ واحد؛ لذا لا يمكن لبيانات اعتماد مقيّدة أن تتجاوز مطلقًا ما تتيحه بيانات الاعتماد غير المقيّدة للمستخدم نفسه. يوفر هذا طريقة ملائمة لإنشاء رموز مميزة للتطبيقات: بيانات اعتماد إضافية ذات تاريخ انتهاء ومجموعة محدودة من الامتيازات، ومرتبطة بالمستخدم؛ إذ تظهر في system.query_log وsystem.processes باسم المستخدم، وتتوقف عن العمل إذا حُذف المستخدم، وتفقد حقوق الوصول عندما يفقدها المستخدم.

يُفرض القيد على العقدة البادئة فقط. يُفرض حد GRANTS لطريقة المصادقة وانتهاء صلاحية VALID UNTIL الخاص بها فقط على العقدة التي تتلقى الاستعلام (العقدة البادئة). ولا يتم تمريرهما إلى العقد الأخرى في العنقود، لذا لا تعتمد على العبارة لتقييد التنفيذ على مستوى العنقود. تحتفظ العقد البعيدة بنطاق الأدوار المعتاد لديها. كما أن العبارة غير متاحة في users.xml. تكون ذاكرة التخزين المؤقت لنتائج الاستعلام مشتركة بين جميع طرق مصادقة المستخدم: فهي تعزل الإدخالات حسب المستخدم والأدوار، ولا يُعاد التحقق من إصابة الذاكرة المؤقتة مقابل GRANTS للطريقة التي سجّلت الجلسة الدخول بها.

أمثلة:

CREATE USER name1 IDENTIFIED BY 'qwerty' GRANTS (SELECT ON db.*)
ALTER USER name1 ADD IDENTIFIED WITH plaintext_password BY 'app_token' VALID UNTIL '2026-12-31' GRANTS (SELECT ON db.table, INSERT ON db.table)

لاحظ أن القيد خاصية لطريقة المصادقة ويُحدَّد عند تسجيل الدخول: يؤثر تغيير العبارة باستخدام ALTER USER في الجلسات الجديدة، لا في الجلسات المنشأة بالفعل. امتيازات المصدر المُرشَّحة، مثل READ ON S3('s3://bucket/.*')، غير مدعومة في العبارة بعد: إذ يقارن التقاطع مرشح المصدر كسلسلة معتمة ولا يمكنه تضييق مرشح ليطابق مرشحًا آخر، لذا يُرفض هذا الامتياز بدلًا من عدم منح أي وصول بصمت. العبارة مدعومة فقط لطرق المصادقة التي يتحقق الخادوم من بيانات اعتمادها محليًا بالكامل. أما الطرق التي يتصل فيها التحقق (أو قد يتصل، في حالة jwt، مثلًا لجلب مفاتيح التوقيع) بنظام خارجي (ldap أو kerberos أو http أو jwt)، فتُرفض العبارة: فعندما تقبل عدة طرق مصادقة بيانات الاعتماد نفسها، يُفرض القيد بإعادة التحقق من بيانات الاعتماد وفق الطرق الأخرى، وإجراء فحص إضافي لنظام خارجي ليس آمنًا؛ لذا قد تتجاوز طريقة أخرى تقبل بيانات الاعتماد نفسها القيد. عندما تقبل أكثر من طريقة مصادقة بيانات الاعتماد الفعلية نفسها، يُقيَّد تسجيل الدخول، بأسلوب الفشل الآمن، بجميعها: تحصل الجلسة على تقاطع GRANTS لجميع الطرق المطابقة، وتنتهي صلاحيتها عند أسبق قيم VALID UNTIL الخاصة بها. وتكون الأولوية لأسبق قيمة VALID UNTIL حتى إن كانت قد انقضت بالفعل — إذ يُرفض تسجيل الدخول، تمامًا كما لو أن الطريقة المطابقة الوحيدة قد انتهت صلاحيتها؛ وبذلك لا يؤدي انتهاء صلاحية رمز مميز إلى منح بيانات الاعتماد المشتركة، بصمت، حقوق أو مدة صلاحية طريقة أوسع. لا يُتحقق من هذا الدمج إلا بين طرق المصادقة التي يتحقق الخادم منها محليًا، للسبب نفسه الذي تُرفض من أجله العبارة نفسها مع طريقة مصادقة يُتحقق منه خارجيًا، كما ذُكر أعلاه: إذ إن إعادة التحقق من بيانات الاعتماد في هذه الحالة ستتطلب فحصًا إضافيًا غير آمن للنظام الخارجي. لذلك، إذا كانت بيانات الاعتماد نفسها مقبولة أيضًا عبر طريقة مصادقة يُتحقق منه خارجيًا (ldap أو kerberos أو http أو jwt) للمستخدم نفسه، فإن VALID UNTIL الخاص بذلك الأسلوب لا يدخل ضمن هذا الدمج، ولا يؤدي ضبط تاريخ انتهاء أسبق له إلى تقصير الجلسة التي تم الحصول عليها عبر طريقة المصادقة الذي يُتحقق منه محليًا.

بند GRANTEES

يحدّد المستخدمين أو الأدوار المسموح لهم بتلقّي الامتيازات من هذا المستخدم، بشرط أن يكون هذا المستخدم قد مُنح أيضًا جميع امتيازات الوصول المطلوبة باستخدام GRANT OPTION. خيارات بند GRANTEES:

user — يحدّد مستخدمًا يمكن لهذا المستخدم منح الامتيازات إليه.
role — يحدّد دورًا يمكن لهذا المستخدم منح الامتيازات إليه.
ANY — يمكن لهذا المستخدم منح الامتيازات لأي شخص. وهذا هو الإعداد الافتراضي.
NONE — لا يمكن لهذا المستخدم منح الامتيازات إلى أي شخص.

يمكنك استثناء أي مستخدم أو دور باستخدام التعبير EXCEPT. على سبيل المثال: CREATE USER user1 GRANTEES ANY EXCEPT user2. وهذا يعني أنه إذا كانت بعض الامتيازات قد مُنحت إلى user1 باستخدام GRANT OPTION، فسيتمكن من منح هذه الامتيازات لأي شخص باستثناء user2.

أمثلة

أنشئ حساب المستخدم mira بكلمة المرور qwerty:

CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty';

يجب أن يشغّل mira تطبيق العميل على المضيف الذي يعمل عليه خادم ClickHouse. أنشئ حساب المستخدم john وعيّن الأدوار:

CREATE USER john ROLE role1, role2;

أنشئ حساب المستخدم john، وعيّن الأدوار واجعل بعضًا منها افتراضيًا:

CREATE USER john ROLE role1, role2 DEFAULT ROLE role1;

أو

CREATE USER john ROLE role1, role2 DEFAULT ROLE ALL EXCEPT role2;

أنشئ حساب المستخدم john واسمح له بمنح امتيازاته للمستخدم صاحب الحساب jack:

CREATE USER john GRANTEES jack;

استخدم معلمة استعلام لإنشاء حساب المستخدم john:

SET param_user=john;
CREATE USER {user:Identifier};

SQL Reference

Data Types

Engines

Functions

Formats

Interfaces

Settings

System Tables

Data Lakes

تحديد الهوية

أمثلة

مضيف المستخدم

عبارة VALID UNTIL

عبارة VALID FOR

عبارة GRANTS

بند GRANTEES

أمثلة

​تحديد الهوية

​أمثلة

​مضيف المستخدم

​عبارة VALID UNTIL

​عبارة VALID FOR

​عبارة GRANTS

​بند GRANTEES

​أمثلة

تحديد الهوية

أمثلة

مضيف المستخدم

عبارة VALID UNTIL

عبارة VALID FOR

عبارة GRANTS

بند GRANTEES

أمثلة