Access Server bỏ qua script post_auth mà bạn đã sửa trên đĩa

Một mac.py đã sửa mà không thay đổi gì là triệu chứng đầu tiên thường gặp. Tệp trên đĩa không phải là thứ Access Server thực thi; dịch vụ xác thực tải script từ cơ sở dữ liệu cấu hình của máy chủ, và chính bản sao đã lưu đó quyết định một lần đăng nhập. Cho đến khi giá trị đã lưu được thay thế, mọi thử nghiệm chỉ chứng minh script cũ vẫn còn hoạt động.

Ba điều kiện quyết định công việc: giá trị đã từng được đưa vào cơ sở dữ liệu cấu hình hay chưa, dịch vụ có được lệnh tải lại nó hay không, và mã bạn đã sửa có thực sự chạy trên mỗi kết nối hay không. Mỗi điều kiện có triệu chứng khác nhau, và sửa sai chỗ sẽ lãng phí một khung bảo trì.

Tệp là nguồn, không phải bản sao đang chạy

Access Server giữ script post-auth dưới khóa auth.module.post_auth_script. Sửa tệp chỉ cập nhật bản sao làm việc của bạn. Daemon đọc giá trị đã lưu, nên thay đổi vẫn vô hình cho đến khi bạn xóa mục cũ và đặt tệp mới vào vị trí của nó. Giá trị đã lưu đó là bản sao duy nhất mà dịch vụ xác thực xem xét.

Hãy đọc nó trước khi thay đổi. Nếu nó đã khớp với tệp bạn sửa, vấn đề không nằm ở lưu trữ và hãy chuyển sang câu hỏi về phạm vi. Nếu nó hiển thị phiên bản cũ hơn, thay đổi chưa bao giờ đến được dịch vụ.

./sacli -k auth.module.post_auth_script ConfigGet

Thay bản sao đã lưu, rồi áp dụng nó

Xóa trước khi ghi không phải là trang trí. ConfigPut với --value_file thay giá trị trong một bước, và ConfigDel trước tiên khiến việc để lại một mục cũ hoặc hỏng trở nên bất khả thi. Hãy giữ một bản sao của script đang hoạt động bên ngoài thư mục script trước khi bắt đầu.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start áp dụng cấu hình đã thay đổi cho các dịch vụ nội bộ, và đó là điều làm script mới có hiệu lực. Nó không giống như khởi động lại toàn bộ máy hoặc daemon, và không nên thay thế bằng việc đó trừ khi thay đổi của bạn yêu cầu.

Dùng đường dẫn tuyệt đối cho tệp giá trị và xác nhận root có thể đọc nó. Một đường dẫn phân giải được từ shell của bạn nhưng không từ tài khoản dịch vụ sẽ tạo ra giá trị đã lưu trông đúng trong ConfigGet và thất bại ở lần đăng nhập đầu tiên. Kiểm tra lại kết quả đã lưu sau sacli start, không phải trước đó.

Phạm vi mô-đun hay theo từng kết nối: truy vấn nên nằm ở đâu

Python thực thi các câu lệnh cấp mô-đun một lần, khi script được tải. Vì vậy một truy vấn cơ sở dữ liệu viết ở đầu tệp sẽ đọc bảng tại thời điểm tải và giữ câu trả lời đó cho mọi kết nối sau. Đây là lý do thứ hai khiến một thay đổi có vẻ không làm gì: mã chạy, nhưng không phải lúc bạn mong đợi.

Đặt truy vấn bên trong trình xử lý post_auth để nó chạy ở mỗi lần xác thực. Giữ nguyên chữ ký đã ghi tài liệu, điều chỉnh kết quả xác thực mà trình xử lý nhận được, và trả về chính đối tượng đó thay vì một con số trần.

Giữ cả việc xử lý kết nối bên trong trình xử lý. Một kết nối mở khi nhập có thể bị máy chủ đóng trước khi người dùng đầu tiên đăng nhập, và lỗi phát sinh trông giống thông tin đăng nhập bị từ chối hơn là một script hỏng.

Hai đường từ chối, một chủ sở hữu

Nếu quyết định là một truy vấn cục bộ, trình xử lý Python sở hữu kết quả. Nếu đó là kiểm tra HTTP bên ngoài, hãy để trạng thái thoát của lệnh mang câu trả lời: một lớp bọc thoát với mã khác không sẽ từ chối đăng nhập, và trạng thái của lệnh cuối cùng trở thành trạng thái của script mà không cần exit rõ ràng.

Giữ bí mật ngoài danh sách tiến trình. Một tệp mà root đọc được hoặc một giá trị môi trường do dịch vụ truyền đi an toàn hơn một đối số mà bất kỳ người dùng cục bộ nào cũng có thể đọc từ ps. Ghim điểm cuối vào một biến trước khi gọi, để lỗi đánh máy thất bại lúc cấu hình chứ không phải trong lúc ai đó đăng nhập. Luân chuyển bí mật đó như mọi thông tin đăng nhập khác.

Chọn một chủ sở hữu cho mỗi lần kiểm tra. Một script vừa truy vấn cơ sở dữ liệu vừa gọi dịch vụ HTTP cần một quy tắc ưu tiên được công bố cho trường hợp hai bên không đồng ý, nếu không lý do từ chối trong nhật ký sẽ không khớp với điều đã nói với người dùng.

Áp dụng mà không khóa quản trị viên

Hai biện pháp làm cho thay đổi có thể đảo ngược: một tài khoản quản trị thứ hai không phụ thuộc vào script, và một bản sao tốt đã biết được giữ ngoài thư mục script. Áp dụng thay đổi trong khung bảo trì, sau đó quan sát một lần đăng nhập thử và một lần từ chối có chủ ý trước khi ngắt kết nối. Nếu nhật ký hiển thị lỗi cú pháp thay vì quyết định xác thực, script đã lưu bị hỏng và mọi lần đăng nhập sẽ thất bại.

Hai điều kiện nói hãy chờ: bạn không thể đọc tệp giá trị với quyền root, hoặc bạn không có đường thứ hai vào giao diện quản trị. Cả hai biến một thay đổi nhỏ thành khóa ngoài, và không cái nào đáng thử trên máy chủ sản xuất vào cuối ngày. Tài liệu Access Server đề cập giao diện post-auth và các trường được hỗ trợ.