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

> مرجع USER

# CREATE USER

ينشئ [حسابات المستخدمين](/ar/concepts/features/security/access-rights#user-account-management).

الصيغة:

```sql theme={null}
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 الموزّع](/ar/reference/statements/distributed-ddl).

<div id="identification">
  ## تحديد الهوية
</div>

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

* `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](/ar/concepts/features/configuration/server-config/configuration-files). فيما يلي مثال على تهيئة تشترط أن تتكون كلمات المرور من 12 حرفًا على الأقل وأن تحتوي على رقم واحد. وتتطلب كل قاعدة من قواعد تعقيد كلمة المرور تعبيرًا نمطيًا لمطابقة كلمات المرور، بالإضافة إلى وصف للقاعدة نفسها.

```xml theme={null}
<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>
```

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

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

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

1. اسم الـ username التالي هو `name1` ولا يتطلب كلمة مرور، وهو ما لا يوفر بطبيعة الحال قدرًا كبيرًا من الأمان:

   ```sql theme={null}
   CREATE USER name1 NOT IDENTIFIED
   ```

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

   ```sql theme={null}
   CREATE USER name2 IDENTIFIED WITH plaintext_password BY 'my_password'
   ```

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

3. الخيار الأكثر شيوعًا هو استخدام كلمة مرور مُجزّأة باستخدام SHA-256. سيتولى ClickHouse تجزئة كلمة المرور نيابةً عنك عند تحديد `IDENTIFIED WITH sha256_password`. على سبيل المثال:

   ```sql theme={null}
   CREATE USER name3 IDENTIFIED WITH sha256_password BY 'my_password'
   ```

   يمكن للمستخدم `name3` الآن تسجيل الدخول باستخدام `my_password`، لكن كلمة المرور تُخزَّن على هيئة قيمة التجزئة المذكورة أعلاه. ويُنشأ ملف SQL التالي في `/var/lib/clickhouse/access` ويُنفَّذ عند بدء تشغيل الخادم:

   ```bash theme={null}
   /var/lib/clickhouse/access $ cat 3843f510-6ebd-a52d-72ac-e021686d8a93.sql
   ATTACH USER name3 IDENTIFIED WITH sha256_hash BY '0C268556C1680BEF0640AAC1E7187566704208398DA31F03D18C74F5C5BE5053' SALT '4FB16307F5E10048196966DD7E6876AE53DE6A1D1F625488482C75F14A5097C7';
   ```

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

4. لا تكون `double_sha1_password` مطلوبة عادةً، لكنها تكون مفيدة عند العمل مع العملاء الذين يتطلبونها (مثل MySQL interface):

   ```sql theme={null}
   CREATE USER name4 IDENTIFIED WITH double_sha1_password BY 'my_password'
   ```

   يُنشئ ClickHouse الاستعلام التالي ويشغّله:

   ```response theme={null}
   CREATE USER name4 IDENTIFIED WITH double_sha1_hash BY 'CCD3A959D6A004B9C3807B728BC2E55B67E10518'
   ```

5. يُعد `bcrypt_password` الخيار الأكثر أمانًا لتخزين كلمات المرور. فهو يستخدم خوارزمية [bcrypt](https://en.wikipedia.org/wiki/Bcrypt)، وهي مقاومة لهجمات القوة الغاشمة حتى إذا أصبحت قيمة تجزئة كلمة المرور compromised.

   ```sql theme={null}
   CREATE USER name5 IDENTIFIED WITH bcrypt_password BY 'my_password'
   ```

   يقتصر طول كلمة المرور في هذه الطريقة على 72 حرفًا.
   كما يمكن تعديل معلمة عامل العمل الخاصة بـ bcrypt، التي تحدد مقدار العمليات الحسابية والوقت اللازمين لحساب التجزئة والتحقق من كلمة المرور، في إعدادات الخادم:

   ```xml theme={null}
   <bcrypt_workfactor>12</bcrypt_workfactor>
   ```

   يجب أن تكون قيمة عامل العمل بين 4 و31، والقيمة الافتراضية هي 12.

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

6. يمكن أيضًا حذف نوع كلمة المرور:

   ```sql theme={null}
   CREATE USER name6 IDENTIFIED BY 'my_password'
   ```

   في هذه الحالة، سيستخدم ClickHouse نوع كلمة المرور الافتراضي المحدد في إعدادات الخادم:

   ```xml theme={null}
   <default_password_type>sha256_password</default_password_type>
   ```

   أنواع كلمات المرور المتاحة هي: `plaintext_password`, `sha256_password`, `double_sha1_password`.

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

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

ملاحظات:

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

<div id="user-host">
  ## مضيف المستخدم
</div>

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

* `HOST IP 'ip_address_or_subnetwork'` — لا يمكن للمستخدم الاتصال بـ خادم ClickHouse إلا من عنوان IP المحدد أو من [شبكة فرعية](https://en.wikipedia.org/wiki/Subnetwork). أمثلة: `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](http://www.pcre.org/) عند تحديد مضيفات المستخدمين. على سبيل المثال، `HOST REGEXP '.*\.mysite\.com'`.
* `HOST LIKE 'template'` — يتيح لك استخدام المعامل [LIKE](/ar/reference/functions/regular-functions/string-search-functions#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`.

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

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

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

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

<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).

أمثلة:

* `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` أبدًا.

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

تتيح لك تقييد حقوق الوصول المتاحة لجلسة تمت مصادقتها باستخدام طريقة مصادقة محددة. وتقبل قائمة بالامتيازات، بين قوسين، بالصيغة نفسها المستخدمة في عبارة [GRANT](/ar/reference/statements/grant). تُحدَّد العبارة بعد طريقة المصادقة (وبعد عبارة `VALID UNTIL` الخاصة بها، إن وُجدت)، ولا تنطبق إلا على تلك الطريقة.

عندما يسجّل مستخدم الدخول باستخدام طريقة مصادقة كهذه، تكون حقوق وصول الجلسة هي تقاطع حقوق وصول المستخدم (بما فيها الحقوق الناتجة عن الأدوار الممنوحة) والامتيازات المدرجة في العبارة. ولا تضيف العبارة أي حقوق وصول مطلقًا: فإذا لم يكن امتياز مدرج ممنوحًا للمستخدم، فلن تمتلكه الجلسة. كذلك، لا تستطيع الجلسات التي تمت مصادقتها بهذه الطريقة منح امتيازات (إذ لا يبقى `GRANT OPTION` بعد التقاطع) أو إدارة الأدوار. ولا تقتصر إدارة الأدوار على إنشائها وتعديلها وحذفها ومنحها وسحبها، بل تشمل أيضًا تغيير الأدوار المفعّلة افتراضيًا للمستخدم (`SET DEFAULT ROLE` و`ALTER USER ... DEFAULT ROLE`)، وهو أمر مرفوض أيضًا.

تبدّل `EXECUTE AS` الكيان الأساسي للجلسة، لذا تقتصر العبارة التي تعمل بانتحال الهوية على تقاطع حقوق وصول المستخدم **الهدف** والامتيازات المدرجة، بدلًا من حقوق المستخدم الذي سجّل الدخول. ولا يُرفع القيد نفسه مطلقًا، ويتطلب انتحال الهوية أن يكون `IMPERSONATE ON target` ممنوحًا للمستخدم ومدرجًا في العبارة في آنٍ واحد؛ لذا لا يمكن لبيانات اعتماد مقيّدة أن تتجاوز مطلقًا ما تتيحه بيانات الاعتماد غير المقيّدة للمستخدم نفسه.

يوفر هذا طريقة ملائمة لإنشاء رموز مميزة للتطبيقات: بيانات اعتماد إضافية ذات تاريخ انتهاء ومجموعة محدودة من الامتيازات، ومرتبطة بالمستخدم؛ إذ تظهر في `system.query_log` و`system.processes` باسم المستخدم، وتتوقف عن العمل إذا حُذف المستخدم، وتفقد حقوق الوصول عندما يفقدها المستخدم.

<Warning>
  **يُفرض القيد على العقدة البادئة فقط.** يُفرض حد `GRANTS` لطريقة المصادقة وانتهاء صلاحية `VALID UNTIL` الخاص بها فقط على العقدة التي تتلقى الاستعلام (العقدة البادئة). ولا **يتم** تمريرهما إلى العقد الأخرى في العنقود، لذا لا تعتمد على العبارة لتقييد التنفيذ على مستوى العنقود. تحتفظ العقد البعيدة بنطاق الأدوار المعتاد لديها. كما أن العبارة غير متاحة في `users.xml`. تكون [ذاكرة التخزين المؤقت لنتائج الاستعلام](/ar/concepts/features/performance/caches/query-cache) مشتركة بين جميع طرق مصادقة المستخدم: فهي تعزل الإدخالات حسب المستخدم والأدوار، ولا يُعاد التحقق من إصابة الذاكرة المؤقتة مقابل `GRANTS` للطريقة التي سجّلت الجلسة الدخول بها.
</Warning>

أمثلة:

* `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` الخاص بذلك الأسلوب لا يدخل ضمن هذا الدمج، ولا يؤدي ضبط تاريخ انتهاء أسبق له إلى تقصير الجلسة التي تم الحصول عليها عبر طريقة المصادقة الذي يُتحقق منه محليًا.

<div id="grantees-clause">
  ## بند GRANTEES
</div>

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

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

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

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

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

```sql theme={null}
CREATE USER mira HOST IP '127.0.0.1' IDENTIFIED WITH sha256_password BY 'qwerty';
```

يجب أن يشغّل `mira` تطبيق العميل على المضيف الذي يعمل عليه خادم ClickHouse.

أنشئ حساب المستخدم `john` وعيّن الأدوار:

```sql theme={null}
CREATE USER john ROLE role1, role2;
```

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

```sql theme={null}
CREATE USER john ROLE role1, role2 DEFAULT ROLE role1;
```

أو

```sql theme={null}
CREATE USER john ROLE role1, role2 DEFAULT ROLE ALL EXCEPT role2;
```

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

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

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

```sql theme={null}
SET param_user=john;
CREATE USER {user:Identifier};
```