npm dist-tag OIDC-д шилжив: удаан настай токен хэрэггүй боллоо

GitHub 2026 оны 9 дүгээр сарын 30-ны мэдэгдэлдээ npm trusted publishing-ийн тохиргоонд dist-tag удирдах тусдаа зөвшөөрөл нэмснийг зарлав. Release-ийн дараа latest, next, beta шошгыг хөдөлгөх, rollback хийхдээ шошгыг өмнө нийтэлсэн хувилбар руу буцаах ажиллагаа одоо богино хугацааны OIDC итгэмжлэлээр явагдаж болно. Өмнө нь багцаа OIDC-ээр нийтэлдэг баг ч ийм ажиллагаанд зориулж удаан настай npm access token хадгалах шаардлагатай байв.

Энэ эрх шинэ болон өмнө бүртгэсэн trusted publisher тохиргоонд анхдагчаар унтраалттай. npm-ийн албан зааварт dist-tag-ийг OIDC-ээр удирдахад npm CLI-ийн 11.21.0 буюу түүнээс шинэ 11.x, эсвэл 12.2.0 буюу түүнээс шинэ 12.x хувилбар, мөн Node.js 22.14.0 буюу түүнээс шинэ хувилбар шаардлагатай гэж заасан. Иймээс багцаа OIDC-ээр нийтэлж чаддаг хуучин pipeline шошго өөрчлөх командыг шинэчлэлгүйгээр ажиллуулж чадна гэж үзэж болохгүй.

Dist-tag-ийн эрхийг тусад нь асаана

Dist-tag бол registry-д аль хэдийн байгаа хувилбар руу заадаг нэр. latest-ийг өөр хувилбар руу шилжүүлэхэд багц дахин нийтлэгдэхгүй, харин хувилбар заалгүй суулгах дараагийн хүсэлтүүдийн сонголт өөрчлөгдөнө. next болон beta нь туршилтын эсвэл дараагийн хувилбарыг тусад нь заахад хэрэглэгддэг. Тиймээс шошго хөдөлгөх эрх нь release pipeline-ийн бодит нөлөөг өөрчилнө.

Багцын npmjs.com дахь Settings → Trusted publishing хэсэгт шошго удирдах ёстой тохиргооны Allow npm dist-tag сонголтыг асаана. Энэ зөвшөөрөл нь шууд нийтлэх npm publish эрхээс хараат бус: workflow-д npm stage publish болон dist-tag удирдах эрх өгөөд, шууд нийтлэх эрхийг өгөхгүй байж болно. Нэг багцад хэд хэдэн trusted publisher бүртгэлтэй бол OIDC таних мэдээлэл dist-tag эрхтэй тэдгээрийн аль нэгтэй таарахад шошго өөрчлөх ажиллагаа зөвшөөрөгдөнө.

Тиймээс зөвхөн release эсвэл rollback хийхээр сонгосон workflow-д энэ эрхийг өгнө. Нийтлэх, батлуулах, шошго дэвшүүлэх ажлыг өөр өөр workflow гүйцэтгэдэг бол тэдгээрийн бүгдэд ижил эрх хэрэггүй. Эрхийг асаасан ч npm CLI тохирох CI орчноос OIDC таних мэдээлэл авч чадах ёстой; багцын тохиргоонд зөвшөөрөл байгаа нь дангаараа ажиллагааг эхлүүлэхгүй.

GitHub Actions, GitLab CI, CircleCI-д тааруулах зүйлс

Эдгээр орчинд ижил дараалал үйлчилнэ: npm дээр багцын trusted publisher-ийг бүртгэж, CI ажлын урсгалд npm-д зориулсан OIDC таних мэдээлэл олгоно. npm CLI тэр мэдээллээр registry-д хэрэглэх богино хугацааны итгэмжлэл авч, dist-tag командыг ажиллуулна. Бүртгэлийн талбарууд CI үйлчилгээ бүрт өөр тул ижил нэртэй төсөл байсан ч буруу workflow эсвэл pipeline-ийг зөвшөөрөхөөс сэргийлж яг тааруулах хэрэгтэй.

• GitHub Actions-д npm дээр GitHub байгууллага эсвэл хэрэглэгчийн нэр, repository, мөн .github/workflows доторх workflow файлын нэрийг бүртгэнэ. Файлын бүтэн замыг бус, өргөтгөлтэй нэрийг оруулна. Тухайн workflow-д id-token: write эрх олгож, npm registry-г ашиглахаар тохируулна; нийтлэх команд өөр файлд байгаа дуудагдсан workflow ашигладаг бол дуудагч workflow-ийн нэр мөн чухал.
• GitLab CI/CD-д namespace, project болон үндсэн CI файлын замыг npm дээр тааруулна. Pipeline-ийн id_tokens тохиргоонд NPM_ID_TOKEN үүсгэж, audience-ийг npm:registry.npmjs.org гэж өгнө. Ийнхүү олгосон таних мэдээллийг npm CLI ашиглах тул dist-tag алхам ажиллах job-д тэр хувьсагч хүрч байх ёстой.
• CircleCI-д байгууллагын ID, төслийн ID, pipeline definition ID болон VCS origin-ийг бүртгэнэ. CI job нь npm-д зориулсан audience-тай OIDC токен авч NPM_ID_TOKEN орчны хувьсагчид өгнө. Нэвтрэх хүрээг нарийсгах шаардлагатай бол npm-ийн тохиргоонд CircleCI context-ийн ID-г мөн зааж болно.

CI-д хуучин npm бичих токен үлдсэн бол CLI уламжлалт нэвтрэлтийг ашиглах боломжтой. Тиймээс OIDC руу шилжсэн эсэхийг зөвхөн тохиргооны нэрээр дүгнэхгүй, яг dist-tag өөрчлөх workflow-ийн ажиллагаагаар батална. Хувийн npm dependency татдаг pipeline-д суулгах алхмын тусдаа унших эрхтэй итгэмжлэл шаардлагатай байж болно; шинэ dist-tag эрх тэр хэрэгцээг орлохгүй.

Stage-only release-ээс latest руу дэвшүүлэх нь

Stage-only урсгалд CI багцыг npm stage publish командаар хяналтад оруулж, эрх бүхий хүн түүнийг шалган баталсны дараа хувилбар registry-д нийтлэгдэнэ. Батлах npm stage approve ажиллагаа OIDC-тэй автомат workflow-ийн эрхэд багтахгүй; хүн интерактив нэвтрэлтээр батална. Ийм зааг тавьснаар CI шинэ хувилбарыг бэлдэж, дараа нь зөвшөөрөгдсөн workflow нийтлэгдсэн хувилбарын шошгыг удирдаж чадна.

Нөхцөлт жишээнд шинэ хувилбарыг эхлээд npm stage publish --tag next гэж оруулъя. Батлагдаж нийтлэгдсэний дараа тэр хувилбарыг next-ээр авах боломжтой болно. Хэрэв pipeline-ийг stage-only хэвээр үлдээх зорилготой бол npm publish эрхийг нэмж асаах шаардлагагүй; харин latest-ийг дэвшүүлэх workflow-д Allow npm dist-tag идэвхтэй байх ёстой. Шошго нь зөвхөн нийтлэгдсэн хувилбар руу заах тул батлагдаагүй staged хувилбарыг latest болгох алхам урьдчилан ажиллахгүй.

Жишээний багцыг example-package, шинээр батлагдсан хувилбарыг <шинэ-хувилбар> гэж тэмдэглэвэл дэвшүүлэх команд нь npm dist-tag add example-package@<шинэ-хувилбар> latest байна. Үүний өмнө болон дараа npm dist-tag ls example-package ажиллуулж заалтыг харж болно. Энэ команд багцын агуулгыг өөрчлөхгүй, зөвхөн latest нэр ямар хувилбар руу заахыг сольдог.

Rollback хийсний дараа хуучин токеныг цуцална

Шинэ хувилбараас буцах шаардлага гарвал өмнө нийтэлсэн, ашиглахад тохиромжтой хувилбарыг latest-д дахин заана. Нөхцөлт жишээнд npm dist-tag add example-package@<өмнөх-хувилбар> latest гэж ажиллуулаад npm dist-tag ls example-package командаар заалтыг харна. Rollback нь шинэ хувилбарыг registry-ээс устгахгүй; цаашид latest нэрээр хувилбар сонгох хүсэлтийн чиглэлийг өөрчилнө. Өмнөх хувилбар registry-д нийтлэгдсэн байх ёстой.

Зөвшөөрөл хүрэлцэхгүй гэсэн алдаа гарвал яг тэр workflow-ийн OIDC таних мэдээлэл npm дээр бүртгэсэн тохиргоотой таарч байгаа эсэх, мөн уг тохиргоонд Allow npm dist-tag асаалттай эсэхийг шалгана. npm whoami нь trusted publishing-ийн dist-tag эрхийг батлах сорил биш; хийх гэж буй ажиллагааг өөрийг нь ажиллуулах шаардлагатай. Stage publish амжилттай болсон ч dist-tag эрх тусдаа тул шошго хөдөлгөх алхам зөвшөөрөлгүй байж болно.

Tech AI Wire-ийн шилжилтийн тойм OIDC урсгал амжилттай ажилласны дараа CI-д хадгалсан хуучин нууцыг устгаж, npm талын ашиглагдахгүй access token-ийг цуцлахыг зөвлөсөн. Зөвшөөрлийг асаах үйлдэл хуучин токеныг автоматаар цуцлахгүй. Release болон rollback хоёул OIDC-ээр ажиллаж буйг тогтоосны дараа л тэр токеныг хасвал шошго удирдахын төлөө хадгалж байсан удаан настай бичих эрх pipeline-д үлдэхгүй.

Мөн уншаарай:

• GitHub Actions-д AWS key хадгалах хэрэггүй: OIDC-г нөхцөлтэй холбо
• Facebook Privacy Checkup хангалтгүй: tag, хуучин постоо давхар шалга