Vòng lặp chuyển hướng Magento của bạn có lẽ không phải do VPN

Bạn thấy 302 trong nhật ký truy cập, cửa hàng không tải qua VPN, và kết luận tự viết ra. Kết luận đó thường sai theo một cách thú vị. Phản hồi chuyển hướng ghi lại một đích đến mà trình duyệt được bảo phải ghé, và nó không nói gì về việc đường hầm, chứng chỉ hay ứng dụng đã tạo ra vấn đề. Dòng nhật ký là điểm khởi đầu của cuộc điều tra, không phải phát hiện của nó.

302 nói đi đâu, không nói tại sao

Một mục trong nhật ký truy cập ghi lại yêu cầu, trạng thái và kích thước, và thường bỏ qua tiêu đề Location quan trọng. Một lần chuyển hướng có thể hoàn toàn bình thường: tên máy chủ chuẩn, chuẩn hóa dấu gạch chéo cuối, chuyển sang HTTPS. Điều bạn cần là trình tự, vì một bước nhảy và một vòng lặp là những lỗi khác nhau với người chịu trách nhiệm khác nhau. Những bước nhảy lặp lại giữa các lược đồ chỉ vào việc xử lý URL và lược đồ. Còn bước nhảy tới một tên mà trình duyệt không phân giải được lại chỉ vào nơi hoàn toàn khác.

Không điều nào trong số đó là bằng chứng về VPN. Đường hầm là một con đường; chuyển hướng là một chỉ dẫn do ứng dụng viết ra.

Ghi lại chuỗi, không phải dòng nhật ký

Dùng chế độ xem mạng của trình duyệt và ghi bốn trường cho mỗi bước nhảy: URL được yêu cầu, trạng thái, tiêu đề Location và thời gian. Kết thúc bằng phản hồi cuối cùng hoặc bằng lỗi kết nối, vì trường hợp thú vị là bước nhảy không bao giờ hoàn tất. Làm việc này một lần trên đường chạy được và một lần trên đường thất bại, với cùng tài khoản và cùng cách điều hướng. So sánh hai chuỗi đáng giá hơn bất kỳ dòng đơn lẻ nào trong nhật ký.

Giữ bản ghi đó riêng tư. URL mang theo định danh phiên, và một kho lưu trữ trình duyệt đã lưu mang nhiều hơn bạn tưởng. Hãy xóa chuỗi truy vấn trước khi dán bất cứ thứ gì vào phiếu hỗ trợ.

Cách ứng dụng hình dung URL của chính nó

Magento tạo URL tuyệt đối từ cấu hình, với phạm vi theo trang web hoặc chế độ xem cửa hàng. bin/magento config:show web/secure/base_url in ra giá trị mà ứng dụng tin là đúng, và đó thường là tên máy chủ còn sót lại từ một bản dựng hoặc một lần di chuyển thay vì tên trình duyệt đã dùng. Nếu ở đó ghi một máy chủ nội bộ, trình duyệt bị gửi tới nơi nó không thể tới, và không thay đổi đường hầm nào sửa được điều đó.

So sánh URL gốc bảo mật và không bảo mật với các tên công khai trước mắt bạn. Một sự không khớp ở bất kỳ bên nào sẽ tạo ra đúng cái chuyển hướng bạn đang nhìn.

Tiêu đề proxy tin cậy là một hợp đồng

Khi TLS kết thúc tại bộ cân bằng tải, ứng dụng chỉ thấy HTTP thường và phải được cho biết điều ngược lại. Cài đặt tiêu đề offloader nêu tên tiêu đề mà proxy đặt, chẳng hạn giao thức được chuyển tiếp, và ứng dụng tin vào nó khi quyết định lược đồ.

Sự tin cậy đó là hợp đồng với một proxy, không phải một sự cho phép chung. Chấp nhận tiêu đề từ các máy khách tùy ý cho phép bất kỳ ai tự nhận một lược đồ, vì thế nó chỉ thuộc về nơi một proxy được chỉ định đặt nó. Nếu tên tiêu đề và hành vi của proxy không khớp, ứng dụng tạo chuyển hướng tới một lược đồ mà trình duyệt chưa từng dùng, và vòng lặp khép lại. Hãy kiểm tra cấu hình proxy và cài đặt ứng dụng cùng nhau, rồi xóa bộ đệm cấu hình để thay đổi có hiệu lực.

Khi vòng lặp là một phiên, không phải một tuyến

Chuỗi luôn quay về đăng nhập thường là vấn đề cookie. Hãy kiểm tra xem cookie phiên được cấp cho tên máy chủ mà trình duyệt thực sự dùng, và nó có được đánh dấu bảo mật trên một kết nối mà trình duyệt coi là bảo mật hay không. Một cookie gắn với sai miền tạo ra vòng lặp đăng nhập trông giống hệt lỗi định tuyến.

Sửa sự không khớp đã chứng minh tại nơi chịu trách nhiệm, dù đó là URL gốc, miền cookie hay hợp đồng proxy, rồi kiểm thử lại toàn bộ điều hướng thay vì nhìn một 302 biến mất. Tắt các yêu cầu HTTPS để phá vòng lặp là đổi một chuyển hướng lấy một vấn đề tệ hơn. Khi thay đổi xong, hãy kiểm tra đường hầm riêng: yêu cầu một tài nguyên riêng tư đã biết và xác nhận nó đến, để lần chuyển hướng tiếp theo có một đường cơ sở sạch để so sánh.