> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> وثائق USER

# ALTER USER

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

الصيغة:

```sql theme={null}
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](/ar/reference/statements/grant#access-management).

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

<div id="grantees-clause">
  ## عبارة GRANTEES
</div>

تحدّد المستخدمين أو الأدوار المسموح لها بتلقّي [الامتيازات](/ar/reference/statements/grant#privileges) من هذا المستخدم، بشرط أن يكون هذا المستخدم قد مُنِح أيضًا جميع صلاحيات الوصول المطلوبة مع [GRANT OPTION](/ar/reference/statements/grant#granting-privilege-syntax). خيارات عبارة `GRANTEES`:

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

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

<div id="examples">
  ## أمثلة
</div>

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

```sql theme={null}
ALTER USER user DEFAULT ROLE role1, role2
```

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

عيّن جميع الأدوار المُسندة إلى default:

```sql theme={null}
ALTER USER user DEFAULT ROLE ALL
```

إذا عُيِّن دورٌ لمستخدم لاحقًا، فسيصبح دور default تلقائيًا.

عيّن جميع الأدوار المعيّنة كأدوار default، باستثناء `role1` و`role2`:

```sql theme={null}
ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2
```

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

```sql theme={null}
ALTER USER john GRANTEES jack;
```

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

```sql theme={null}
ALTER USER user1 ADD IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'
```

ملاحظات:

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

```sql theme={null}
ALTER USER user1 ADD IDENTIFIED WITH no_password
```

إذا كنت تريد حذف طرق المصادقة لمستخدم والاعتماد على `no_password`، فيجب عليك استخدام صيغة الاستبدال أدناه.

تُعيد تعيين طرق المصادقة وتضيف الطرق المحددة في الاستعلام (وهو تأثير وجود IDENTIFIED في البداية من دون الكلمة المفتاحية ADD):

```sql theme={null}
ALTER USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'
```

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

```sql theme={null}
ALTER USER user1 RESET AUTHENTICATION METHODS TO NEW
```

<div id="valid-until-clause">
  ## عبارة VALID UNTIL
</div>

تتيح تحديد تاريخ انتهاء صلاحية طريقة مصادقة، والوقت اختياريًا. تقبل سلسلة نصية كمعلمة. يُنصح باستخدام التنسيق `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`](/ar/reference/system-tables/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` مطلقًا.

<div id="valid-for-clause">
  ## عبارة VALID FOR
</div>

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

أمثلة:

* `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` مطلقًا.

<div id="grants-clause">
  ## عبارة GRANTS
</div>

تتيح تقييد حقوق الوصول المتاحة لجلسة تمت مصادقتها باستخدام طريقة مصادقة محددة. راجع [عبارة GRANTS في CREATE USER](/ar/reference/statements/create/user#grants-clause) لمزيد من التفاصيل.

وبالاقتران مع `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)`