ALTER USER

يُعدِّل حسابات مستخدمي ClickHouse. الصيغة:

ALTER USER [IF EXISTS] name1 [RENAME TO new_name |, name2 [,...]]
    [ON CLUSTER cluster_name]
    [{VALID UNTIL datetime | VALID FOR interval}]
    [NOT IDENTIFIED | RESET AUTHENTICATION METHODS TO NEW | {IDENTIFIED | ADD 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'} | {...} | ... [,...]]]
    [[ADD | DROP] HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
    [IN access_storage_type]
    [DEFAULT ROLE role [,...] | ALL | ALL EXCEPT role [,...] ]
    [GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
    [DROP ALL PROFILES]
    [DROP ALL SETTINGS]
    [DROP SETTINGS variable [,...] ]
    [DROP PROFILES 'profile_name' [,...] ]
    [ADD|MODIFY SETTINGS variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
    [SET variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
    [ADD PROFILES 'profile_name' [,...] ]

لاستخدام ALTER USER، يجب أن يكون لديك امتياز ALTER USER. SET variable = value هو اسم مستعار لـ MODIFY SETTING variable = value: إذ يغيّر إعدادًا واحدًا فقط مع الإبقاء على بقية الإعدادات كما هي. ويُفضَّل استخدامه (أو MODIFY SETTING) بدلًا من عبارة SETTINGS المجرّدة، لأنها تستبدل قائمة الإعدادات بالكامل وتزيل أيضًا جميع ملفات التعريف الموروثة (الأصل).

عبارة GRANTEES

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

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

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

أمثلة

اجعل الأدوار المُسنَدة default:

ALTER USER user DEFAULT ROLE role1, role2

إذا لم تكن قد أُسنِدت أي أدوار إلى المستخدم مسبقًا، فإن ClickHouse يُصدر استثناءً. عيّن جميع الأدوار المُسندة إلى default:

ALTER USER user DEFAULT ROLE ALL

إذا عُيِّن دورٌ لمستخدم لاحقًا، فسيصبح دور default تلقائيًا. عيّن جميع الأدوار المعيّنة كأدوار default، باستثناء role1 وrole2:

ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2

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

ALTER USER john GRANTEES jack;

يضيف للمستخدم طرق المصادقة جديدة مع الإبقاء على الطرق الحالية:

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

ملاحظات:

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

ALTER USER user1 ADD IDENTIFIED WITH no_password

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

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

أعِد تعيين طرق المصادقة واحتفظ بأحدث طريقة أُضيفت:

ALTER USER user1 RESET AUTHENTICATION METHODS TO NEW

عبارة VALID UNTIL

تتيح تحديد تاريخ انتهاء صلاحية طريقة مصادقة، والوقت اختياريًا. تقبل سلسلة نصية كمعلمة. يُنصح باستخدام التنسيق YYYY-MM-DD [hh:mm:ss] [timezone] للتاريخ والوقت. تكون قيمة هذه المعلمة افتراضيًا '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 UTC)، ولذلك يعرض 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 كاملة ترتبط بالطريقة الأخيرة فقط، بينما تبقى الطرق السابقة بلا انتهاء صلاحية.

أمثلة:

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

عبارة 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. أمثلة:

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

عبارة GRANTS

تتيح تقييد حقوق الوصول المتاحة لجلسة تمت مصادقتها باستخدام طريقة مصادقة محددة. راجع عبارة GRANTS في CREATE USER لمزيد من التفاصيل. وبالاقتران مع ADD IDENTIFIED، توفر هذه العبارة طريقة ملائمة لإنشاء رموز مميزة للتطبيقات: بيانات اعتماد إضافية بتاريخ انتهاء صلاحية ومجموعة محدودة من الامتيازات. مثال:

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)

SQL Reference

Data Types

Engines

Functions

Formats

Interfaces

Settings

System Tables

Data Lakes

عبارة GRANTEES

أمثلة

عبارة VALID UNTIL

عبارة VALID FOR

عبارة GRANTS

​عبارة GRANTEES

​أمثلة

​عبارة VALID UNTIL

​عبارة VALID FOR

​عبارة GRANTS

عبارة GRANTEES

أمثلة

عبارة VALID UNTIL

عبارة VALID FOR

عبارة GRANTS