تصدیق

تائید شدہ تصدیق

Crateview گمنام رجسٹریوں، مقامی htpasswd Basic Auth اور اختیاری Crateview auth سروس کو ٹوکن موڈ میں سپورٹ کرتا ہے۔ یہ /v2/ کی تحقیقات کرتا ہے اور جب رجسٹری کو بنیادی تصدیق کی ضرورت ہوتی ہے تو سائن ان فارم دکھاتا ہے۔

بیرونی Bearer ٹوکن خدمات اور OIDC مربوط نہیں ہیں۔ غیر ترتیب شدہ بیرونی ٹوکن سروسز ایک واضح غیر تعاون یافتہ-auth نوٹس تیار کرتی ہیں۔

رجسٹری سائیڈ Basic Auth

ایک bcrypt پاس ورڈ ہیش کے ساتھ htpasswd فائل بنائیں۔ مندرجہ ذیل مثال ایک عارضی آفیشل اپاچی کنٹینر استعمال کرتی ہے۔ مثال کی اسناد کو تبدیل کریں اور نتیجے میں فائل کی حفاظت کریں:

mkdir -p auth
docker run --rm --entrypoint htpasswd httpd:2   -Bbn your-user choose-a-strong-password > auth/htpasswd

مثال Distribution ترتیبات:

auth:
  htpasswd:
    realm: Registry
    path: /auth/htpasswd

تیار کردہ فائل کو /auth/htpasswd پر رجسٹری کنٹینر میں ماؤنٹ کریں۔ رجسٹری کنفیگریشن Crateview کنفیگریشن سے الگ ہے۔ ریموٹ رسائی کے لیے HTTPS استعمال کریں۔ Basic Auth ایک انکوڈنگ ہے، ٹرانسپورٹ انکرپشن نہیں۔ مشترکہ شیل کی تاریخ یا عوامی مثالوں میں اصلی پاس ورڈ چھوڑنے سے گریز کریں۔

UI سیشنز

Nitro سرور رجسٹری کے خلاف اسناد کی توثیق کرتا ہے۔ یہ انہیں ایک انکرپٹڈ، HttpOnly، SameSite=Strict کوکی میں اسٹور کرتا ہے۔ براؤزر JavaScript اور localStorage کو اسناد موصول نہیں ہوتی ہیں۔ سیشن آٹھ گھنٹے بعد ختم ہو جاتے ہیں۔

بے ترتیب پروڈکشن سیشن کا راز مرتب کریں:

openssl rand -base64 32

کم از کم 32 حروف کے ساتھ تیار کردہ قدر کو NUXT_SESSION_PASSWORD کے بطور استعمال کریں۔ لوڈ بیلنسر کے پیچھے ہر فرنٹ اینڈ مثال کو ایک ہی قدر کا استعمال کرنا چاہئے۔ کنفیگریشن کے بغیر، Crateview ایک پروسیس لوکل سیکریٹ تیار کرتا ہے، اس لیے دوبارہ شروع کرنے سے موجودہ سیشنز باطل ہو جاتے ہیں۔

HTTPS اور لاگ آؤٹ

جب عوامی درخواست پروٹوکول HTTPS ہوتا ہے تو سیشن کوکی Secure کا استعمال کرتی ہے۔ ریورس پراکسی کے فارورڈ کردہ پروٹوکول کو صحیح طریقے سے ترتیب دیں۔ سائن آؤٹ کرنے سے UI سیشن صاف ہو جاتا ہے۔ یہ رجسٹری صارفین کو حذف یا ترمیم نہیں کرتا ہے۔

Docker اور دیگر CLI کلائنٹس اپنی عام رجسٹری اسناد کا استعمال کرتے ہوئے /v2/** پراکسی کے ذریعے براہ راست تصدیق کرتے ہیں۔ ویب UI میں سائن ان کرنے سے Docker CLI خود بخود سائن ان نہیں ہوتا ہے۔

اختیاری اکاؤنٹ مینجمنٹ

ایک آزاد auth/مینجمنٹ سروس اکاؤنٹ بنانے اور اپنے پاس ورڈ کی تبدیلیوں کی حمایت کرتی ہے۔ Docker براہ راست رجسٹری سے جڑتا ہے اور UI کنٹینر کے بغیر کام کرتا ہے۔ صارفین اور bcrypt ہیشز htpasswd میں رہتے ہیں۔ ٹوکن کی اجازت permissions.json میں رہتی ہے۔ اکاؤنٹ اسٹوریج SQLite استعمال نہیں کرتا ہے۔

• بنیادی وضع: Distribution مشترکہ htpasswd فائل کو چیک کرتا ہے۔ تمام صارفین کو رجسٹری تک مساوی رسائی حاصل ہے۔ Docker کو چلانے کے لیے مینجمنٹ سروس کی ضرورت نہیں ہے۔
• ٹوکن موڈ: آزاد auth سروس کے ایشوز نے پانچ منٹ کے ٹوکن پر دستخط کیے ہیں۔ Distribution ذخیرہ کی اجازتوں کو نافذ کرتا ہے۔ Docker کو رجسٹری اور auth سروس درکار ہے۔ نئے صارفین کو ابتدائی طور پر ذخیرے تک رسائی نہیں ہے۔
• UI: صارفین موجودہ پاس ورڈ فراہم کرکے اپنا پاس ورڈ تبدیل کرتے ہیں۔ NUXT_USER_CREATION_ALLOWED_USERS ڈیفالٹ سے خالی؛ alice,bob صرف ان صارفین کو اکاؤنٹ بنانے کی اجازت دیتا ہے، * ہر تصدیق شدہ صارف کو اجازت دیتا ہے۔ یہ پالیسی سرور کی طرف سے نافذ ہے۔
• اجازتیں: CLI ٹارگٹ کے عین ذخیرے، نام کی جگہیں (team/*) یا سب کچھ (*); پروفائلز ہیں reader (pull) writer (pull/push)، اور manager (pull/push/حذف کریں)۔ بنیادی وضع میں کوئی رجسٹری رول نہیں ہے۔

واضح طور پر NUXT_AUTH_MODE=htpasswd یا token کو فعال کریں اور اندرونی NUXT_AUTH_SERVICE_URL اور سرور صرف NUXT_AUTH_SERVICE_SECRET کو ترتیب دیں۔ ٹوکن موڈ کے لیے اضافی طور پر NUXT_AUTH_TOKEN_REALM کی ضرورت ہوتی ہے تاکہ عوامی ٹوکن اینڈ پوائنٹ سے بالکل مماثل ہو۔ گمنام رجسٹریاں اور بیرونی ٹوکن سروسز مقامی اکاؤنٹ کے انتظام کو سپورٹ نہیں کرتی ہیں۔ اجازتیں اور انتظامی پاس ورڈ ری سیٹ auth CLI استعمال کرتے ہیں؛ UI دوسرے صارفین کے پاس ورڈ تبدیل نہیں کر سکتا یا اجازتیں تفویض نہیں کر سکتا۔

Compose اوورلیز، سیٹ اپ، منتقلی اور CLI کمانڈز کے لیے اکاؤنٹ سروس گائیڈ دیکھیں۔ UI سے آزادانہ طور پر عوامی Docker براہ راست رجسٹری تک رسائی کا راستہ بنائیں۔ پہلے جاری کردہ ٹوکن پاس ورڈ کی تبدیلی یا اجازت منسوخی کے بعد پانچ منٹ تک درست رہتے ہیں۔