Tự động hóa của bạn nhận một bí mật, lưu trữ nó rồi gửi nó đến GitHub để đọc một kho lưu trữ. Nó hoạt động hôm qua, nhưng một giá trị dài hơn bây giờ bị cắt ngắn khi truyền. Các quyền có thể đúng và truy vấn vẫn thất bại. Kết thúc việc triển khai các mã thông báo cài đặt mới GitHub Apps, được công bố vào ngày 2 tháng 10 năm 2026, mời theo dõi bí mật này trong suốt hành trình của nó.
Xác định bí mật liên quan trước khi tìm khắp nơi
Một GitHub App là một ứng dụng mà bạn cấp quyền trên một tập hợp các kho lưu trữ. Việc cài đặt của nó có một bối cảnh truy cập riêng. Token cài đặt được sử dụng cho các cuộc gọi thực hiện trong bối cảnh này; nó khác với bí mật của người dùng và khóa riêng của ứng dụng.
Tài liệu GitHub tách việc xác thực ứng dụng và việc tạo token cho việc cài đặt của nó. Trước khi kiểm toán, hãy tìm lại thành phần thực sự nhận token này. Một cấu hình chỉ mang tên « token GitHub » không đủ để xác định loại token. Tài liệu về mã thông báo cài đặt.
Ngày 2 tháng 10, GitHub đã thông báo kết thúc việc triển khai bắt đầu từ ngày 27 tháng 4: các token cài đặt mới mặc định sử dụng định dạng stateless. Chúng giữ nguyên tiền tố ghs_ và có khoảng 520 ký tự, so với 40 trước đây. Các quyền, phạm vi của các kho lưu trữ, thời hạn một giờ và endpoint vẫn không thay đổi. Header tạm thời X-GitHub-Stateless-S2S-Token sẽ ngừng được hỗ trợ vào ngày 30 tháng 11 năm 2026. Thông báo kết thúc triển khai.
Stateless mô tả ở đây định dạng mới của nhà cung cấp. Bạn không cần phải hiểu bên trong để truyền đạt bí mật một cách chính xác. Giá trị phải giữ nguyên tính không minh bạch: ứng dụng của bạn vận chuyển nó, nhưng không xây dựng các quy tắc truy cập bằng cách giải mã những gì nó nghĩ là nhận ra ở đó. Thứ tự độ lớn được công bố không phải là một độ dài chính xác mới để áp đặt trong một biểu mẫu.
Vẽ lộ trình thực tế, từ nhà cung cấp đến yêu cầu
Ví dụ giả tưởng của chúng tôi là một công cụ nội bộ dùng để kiểm tra trạng thái các kho lưu trữ. Một dịch vụ lấy mã thông báo, một bộ lưu trữ giữ nó trong thời gian ngắn, một quy trình công việc tải nó và một client HTTP gửi nó. Một giao diện quản trị và một việc thu thập lỗi cũng có thể thao tác với nó. Mỗi bước này có thể giữ một giả định cũ.
Bắt đầu với tên của các biến, thuộc tính và tham số mang giá trị. Sau đó, tìm kiếm các ràng buộc về độ dài của chúng và các phép biến đổi được áp dụng: cắt chuỗi, loại bỏ ký tự, mã hóa hoặc sao chép sang một trường khác. Một ràng buộc có thể đến từ mã, từ sơ đồ cơ sở dữ liệu hoặc từ một thành phần bên ngoài.
Một cột quá ngắn có thể gây ra lỗi rõ ràng, nhưng một số đường dẫn có thể bị cắt ngắn một cách âm thầm. Một trường giao diện có thể từ chối nhập liệu ngay cả trước khi gọi mạng. Một mặt nạ nhật ký có thể chỉ nhận ra bí mật cũ và để lộ một phần bí mật mới. Do đó đừng giảm bớt kiểm tra thành chỉ dòng tạo header xác thực.
| Bộ phận cần kiểm tra | Câu hỏi hữu ích | Bằng chứng được mong đợi |
|---|---|---|
| Dịch vụ cấp | Câu trả lời có được sao chép toàn bộ không? | Giá trị bằng nhau với một giá trị giả |
| Lưu trữ | Năng lực và các kiểm soát có phù hợp không? | Đọc sau khi viết mà không mất dữ liệu |
| Đang tải | Giá trị có bị thay đổi trong khi vận chuyển không? | So sánh trước và sau khi đi qua |
| Client mạng | Phần tiêu đề có chứa giá trị đúng không? | Bắt giữ trong một phương tiện vận chuyển giả lập |
| Nhật ký và lỗi | Một phần của bí mật có xuất hiện không? | Kiểm tra không xuất hiện trong đầu ra |
Bảng này là một đề xuất Partitech. Thêm một người chịu trách nhiệm cho mỗi dòng, vì một bài kiểm tra thành công trên mã ứng dụng không nhất thiết xác nhận được proxy hoặc công cụ lưu trữ do một nhóm khác quản lý.
Kiểm tra một thuộc tính, thay vì một ví dụ về định dạng
Thuộc tính được tìm kiếm là đơn giản: giá trị nhập vào phải giống hệt với giá trị đạt được trong quá trình truyền dự kiến. Một chuỗi thử nghiệm không cần phải giống một bí mật thực sự. Hãy chọn một tiền tố rõ ràng, ví dụ FAUX_SECRET_TEST_, và các kích thước khác nhau, trong đó có một kích thước vượt quá bậc độ lớn đã thông báo. Những giá trị này không bao giờ được phép cho phép xác thực.
Bạn có thể bao gồm một chuỗi ngắn, một chuỗi dài hơn và một giá trị chứa các ký tự mà thành phần của bạn chấp nhận theo hợp đồng của nó. Kích thước là các tham số kiểm tra cục bộ, không phải là ước tính cho các token trong tương lai GitHub. Duy trì các giới hạn hợp lý chống lại các đầu vào lạm dụng; chỉ tránh một giới hạn xuất phát từ một định dạng cũ mà không có lý do kỹ thuật.
Giả mã của kiểm soát được đề xuất, không thực thi ở đây :
pour chaque valeur factice du jeu de test
écrire dans le stockage de test
relire par le chemin de chargement réel
envoyer au client HTTP simulé
vérifier l'égalité avec la valeur de départ
provoquer une erreur de transport simulée
vérifier l'absence de la valeur dans toutes les sorties
Thêm một trường hợp vượt quá cố ý khả năng đã định của thành phần của bạn. Lỗi phải rõ ràng và không được cắt bớt rồi tiếp tục, cũng như không hiển thị nội dung nhận được. Thử nghiệm này kiểm tra chất lượng từ chối; nó không yêu cầu bạn chấp nhận các chuỗi có kích thước vô hạn.
Đối với việc che giấu, hãy tìm kiếm toàn bộ bí mật nhưng cũng các đoạn có thể nhận dạng được có khả năng bị tiết lộ. Một quy tắc che phần đầu và hiển thị phần cuối vẫn là rò rỉ. Kiểm tra phản hồi lỗi, bảng điều khiển, nhật ký có cấu trúc và các tệp đính kèm chẩn đoán có thể có. Hãy thực hiện điều này với các giá trị giả, để việc điều tra không tự trở thành một sự tiết lộ.
Sửa chữa đường biên sai mà không mở rộng quyền truy cập
Nếu bộ nhớ bị cắt bớt, hãy điều chỉnh dung lượng của nó theo các quy ước của ứng dụng của bạn. Nếu một biểu thức chính quy yêu cầu đúng độ dài cũ, hãy thay giả thiết này bằng một kiểm tra phù hợp với việc sử dụng thực tế. Nếu một công cụ chẩn đoán chỉ nhận dạng được một mẫu cũ, hãy ưu tiên loại bỏ thuộc tính bí mật khỏi quá trình thu thập thay vì cố gắng đoán tất cả các dạng tương lai của nó.
Một lỗi định dạng không biện minh cho việc thêm quyền vào ứng dụng. Trong công cụ giả tưởng của chúng tôi, việc đọc kho vẫn là việc đọc kho, ngay cả sau khi sửa chữa lưu trữ. Hãy kiểm tra lại riêng biệt các quyền thực sự cần thiết; đừng nhầm lẫn việc từ chối cục bộ với việc từ chối quyền từ xa.
Khi một thay đổi về lược đồ là cần thiết, hãy chuẩn bị nó bằng cơ chế di trú hiện có. Kiểm tra thứ tự triển khai giữa cơ sở dữ liệu và mã, các phiên bản cũ vẫn còn hoạt động và cách chúng đọc dữ liệu mới. Một ghi chép được mở rộng đúng cách vẫn có thể bị đọc sai bởi một phiên bản vẫn giữ xác thực cũ.
Tránh giữ thêm bí mật để thuận tiện cho việc so sánh. Bằng chứng của bạn có thể ghi "bằng nhau đã được xác minh" và tên của kịch bản thử nghiệm, mà không giữ giá trị. Lưu trữ tạm thời phải giữ được thời hạn và các kiểm soát truy cập của nó. Công việc tập trung vào việc vận chuyển trung thực, không phải nhân bản nhiều lần.
Chuẩn bị cho ngày 30 tháng 11 và giám sát
Thông báo ngày 15 tháng 5 trình bày một header tạm thời cho phép lựa chọn hành vi tạo trong giai đoạn chuyển tiếp. Nó vẫn là một bối cảnh lịch sử, tách biệt với việc kết thúc triển khai được thông báo vào tháng Mười. Thông báo header chuyển tiếp.
Liệt kê các thành phần vẫn đang sử dụng header này. Gán việc xóa cho một phiên bản phát hành, với một người chịu trách nhiệm và một bài kiểm tra khả năng tương thích. Hạn chót ngày 30 tháng 11 đã được thông báo bởi GitHub phải xuất hiện trong theo dõi của bạn: một tùy chọn chuyển tiếp không phải là một cơ chế quay lại vĩnh viễn.
Sau các thử nghiệm tại chỗ, một chứng nhận được phép trên một môi trường GitHub thử nghiệm có thể xác minh việc nhận và sử dụng mã thông báo, với các quyền tối thiểu cần thiết. Nó phải giữ bí mật ngoài các bản ghi chụp. Hãy phân biệt trong báo cáo của bạn những gì việc truyền tải mô phỏng đã chứng minh với những gì cuộc gọi thực tế này đã xác nhận.
Đối với việc giám sát, theo dõi các lỗi theo thành phần và theo bước: thu thập, lưu trữ, tải, truy vấn. So sánh xu hướng trước và sau khi triển khai, không gán một sự cố cho một định dạng chỉ vì nó xuất hiện cùng ngày. Một phản hồi từ chối có thể có nhiều nguyên nhân; bản kiểm kê của bạn cho phép kiểm tra giả thuyết đúng.
Chọn cách quay lại phiên bản trước vẫn tương thích
Quay trở lại một phiên bản cũ hơn cắt bớt các token mới sẽ tái hiện lại vấn đề. Vì vậy, hãy chuẩn bị một phiên bản dự phòng giữ nguyên sửa lỗi tương thích, hoặc một kế hoạch gỡ bỏ thay đổi chức năng mà không phục hồi hạn chế cũ. Hãy ghi lại điểm này trước khi tiến hành triển khai.
Nhiệm vụ có thể được coi là đủ điều kiện khi các đoạn thực tế có một người chịu trách nhiệm, các thử nghiệm giả định giữ nguyên giá trị, các lỗi vẫn không có bí mật và việc gỡ bỏ header tạm thời được lập kế hoạch. Bài viết này không tuyên bố đã thực hiện thử nghiệm trên một tích hợp Partitech.
Cho lần đánh giá kỹ thuật tiếp theo của bạn, hãy chọn một lộ trình duy nhất của mã cài đặt và áp dụng lưới từ đầu đến cuối. Bạn sẽ có được một phạm vi sửa lỗi cụ thể, thay vì viết lại chung về xác thực. Sự vững chắc hữu ích phụ thuộc vào độ trung thực của việc truyền tải và sự kín đáo của các chẩn đoán, bất kể hình thức hiện tại của bí mật.
Nguồn và ngày kiểm tra
Nguồn mở ngày 6 tháng 10 năm 2026 : kết thúc triển khai, header tạm thời tháng 5 và tài liệu GitHub Apps. Các bài kiểm tra được mô tả là một giao thức được đề xuất, không có bí mật chức năng hay kết quả giả mạo.