Lorawan-stack: المستخدم الجديد (المسؤول) ليس لديه أذونات في وحدة التحكم

تم إنشاؤها على ١٤ أغسطس ٢٠١٩  ·  6تعليقات  ·  مصدر: TheThingsNetwork/lorawan-stack

ملخص

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

خطوات التكاثر

لست متأكدا تماما. هناك حالتان هنا قد تكون لهما نفس السبب. في الحالة الأولى ، أعمل على جهاز لم يتم إعداده من قبلي ولدي معلومات محدودة عن هذه العملية.

الحالة 1: مكدس أجنبي ؛ الإعداد كإصدار 3.0.0 وترقيته إلى 3.1.0 قبل استخدام وحدة التحكم.

  1. الإعداد ttn 3.0.0 بعد CLI الشروع في العمل
  2. التحديث إلى 3.1.0
  3. عميل وحدة تحكم الإعداد (ومن المحتمل أن يفسد الأمر *)
  4. إنشاء مستخدم --admin (
    5. تسجيل الدخول إلى وحدة التحكم ومحاولة إنشاء بوابة.

* ما حدث عند الترقية هو أن عملية إنشاء وحدة التحكم تمت باستخدام uris خاطئ ، لذلك قمنا بحذف عميل وحدة التحكم في قاعدة البيانات وأعدنا استخدام الأمر is-db . ربما أخفقنا هنا.

الحالة 2 : في الإعداد الخاص بي:

  1. إعداد ttn بعد الشروع في العمل
  2. إنشاء مستخدم عادي ttn-lw-cli users create norman --name norman --primary-email-address norman@localhost باستخدام المستخدم المسؤول من البدء
  3. حاول إنشاء بوابة أو تطبيق

ماذا ترى الآن؟

في كلتا الحالتين ، تستجيب وحدة التحكم بـ Insufficient rights for user 'myuser' بعد إدخال التفاصيل والضغط على الزر Create Gateway أو Create Application .

لا يوجد شيء غير عادي في وحدة تحكم المتصفح. تعرض علامة تبويب الشبكة استجابة 403 محظورة من ttn.

عند إنشاء تطبيق عبر CLI مع المستخدم الإداري وتخصيصه للمستخدم المعني ، قد يرى المستخدم التطبيق / البوابة ولكن النقر عليه يؤدي إلى 403 Forbidden.

ماذا تريد ان ترى بدلا من ذلك؟

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

أتوقع أيضًا المزيد من الوثائق حول عملية إنشاء المستخدم وكيفية إدارة حقوق المستخدم.

بيئة

The Things Network Stack for LoRaWAN: ttn-lw-stack
Version:             3.1.0
Go version:          go1.12.7
OS/Arch:             linux/amd64

تكوين الحالة 1:
مكدس config.txt

كيف تقترح تنفيذ هذا؟

للأسف ليس لدي فكرة أين تكمن المشكلة.

هل يمكنك القيام بذلك بنفسك وإرسال طلب سحب؟

قد لا أتمكن من تنفيذ إصلاح ولكن يمكنني تقديم الوثائق لإنشاء المستخدم وإدارة الحقوق.

ucli
مصدر
picture w4tsn

التعليق الأكثر فائدة

إذا تم إنشاء مستخدم بواسطة أحد المسؤولين ، فسيتم أخذ الحقول state (و admin ) حرفياً من الطلب. يعمل هذا على النحو المنشود ، نظرًا لأننا لا نعرف ما إذا كان المسؤول قد قام صراحة بتعيين state إلى REQUESTED أم أنه تركه للتو.

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

ستوضح وظيفة "إنشاء مستخدم بواسطة المسؤول" في واجهة مستخدم الويب أن الحقل state يحتاج إلى تعيين ، لكنني أعتقد أنه سيكون من الجيد أن يكون لديك خيار افتراضي أكثر عقلانية من REQUESTED ، فلنغير CLI ونجعل العلم state هو users create APPROVED افتراضيًا.

picture htdvisser في ١٤ أغسطس ٢٠١٩
👍2

ال 6 كومينتر

@ w4tsn ما هو التكوين الخاص بك؟ هل تحتاج إلى موافقة المسؤول للمستخدمين الجدد؟

هل يمكنك إظهار ناتج $ ttn-lw-cli user get myuser --state ؟

johanstokking picture johanstokking في ١٤ أغسطس ٢٠١٩

حالة 1:

{
  "ids": {
    "user_id": "someadmin"
  },
  "created_at": "2019-08-14T07:20:10.542Z",
  "updated_at": "2019-08-14T07:20:10.542Z",
  "password_updated_at": "0001-01-01T00:00:00Z"
}

الحالة 2:

{
  "ids": {
    "user_id": "myuser"
  },
  "created_at": "2019-08-06T10:30:34.091Z",
  "updated_at": "2019-08-06T10:30:34.091Z",
  "password_updated_at": "0001-01-01T00:00:00Z"
}

سوف أقوم بتحديث قسم env مع تكوين حالتي 1. في الحالة الثانية ، لم أقم أيضًا بتعيين موافقة المسؤول بشكل صريح. مطلوب موافقة مسؤول حالة التكوين = خطأ

w4tsn picture w4tsn في ١٤ أغسطس ٢٠١٩

أستطيع أن أؤكد أنه يمكن إعادة إنتاج المشكلة في 3.1.0.
إصلاح محتمل هو استخدام أمر التنشيط اليدوي التالي: ttn-lw-cli users set norman --state=STATE_APPROVED . سأبحث في سبب حدوث ذلك قريبًا.

أيضًا ، في المخرجات أعلاه نظرًا لعدم ذكر الحالة ، فهي صفر ، مما يعني STATE_REQUESTED ، لذلك لم يتم تنشيط المستخدمين بالفعل.

adriansmares picture adriansmares في ١٤ أغسطس ٢٠١٩
👍1

وجدت أيضًا السبب:
https://github.com/TheThingsNetwork/lorawan-stack/blob/55381c15f6902508ea34cd40441ad2bd3146ac37/pkg/identityserver/user_registry.go#L149 -L156
لا يحترم المستخدمون الذين أنشأهم المسؤول إعداد موافقة المسؤول ولديهم دائمًا الحالة الافتراضية ( STATE_REQUESTED ). هل هذا مقصود htdvisser ؟

adriansmares picture adriansmares في ١٤ أغسطس ٢٠١٩

إذا تم إنشاء مستخدم بواسطة أحد المسؤولين ، فسيتم أخذ الحقول state (و admin ) حرفياً من الطلب. يعمل هذا على النحو المنشود ، نظرًا لأننا لا نعرف ما إذا كان المسؤول قد قام صراحة بتعيين state إلى REQUESTED أم أنه تركه للتو.

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

ستوضح وظيفة "إنشاء مستخدم بواسطة المسؤول" في واجهة مستخدم الويب أن الحقل state يحتاج إلى تعيين ، لكنني أعتقد أنه سيكون من الجيد أن يكون لديك خيار افتراضي أكثر عقلانية من REQUESTED ، فلنغير CLI ونجعل العلم state هو users create APPROVED افتراضيًا.

htdvisser picture htdvisser في ١٤ أغسطس ٢٠١٩
👍2

مع # 1190 ، والذي يتضمن الوظيفة التي وصفتها في تعليقي السابق ، أعتقد أنه يمكن إغلاق هذه المشكلة الآن.

htdvisser picture htdvisser في ٢٧ أغسطس ٢٠١٩
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

johanstokking picture johanstokking  ·  8تعليقات
thinkOfaNumber picture thinkOfaNumber  ·  4تعليقات
ecities picture ecities  ·  5تعليقات
johanstokking picture johanstokking  ·  8تعليقات
johanstokking picture johanstokking  ·  5تعليقات