Tôi đang sử dụng khung công tác Express (3.0) trên node.js để định tuyến ứng dụng của mình.Express (node.js) bằng HTTPS và HTTP
Hầu hết đơn đăng ký của tôi sử dụng giao thức http
tuy nhiên, chỉ có một tuyến đường cụ thể mà tôi muốn phân phối qua https
. Đây là một phần của API của tôi chịu trách nhiệm đăng ký và xác thực người dùng.
ví dụ:
app.get('/connect', function(req, res){
// Must be on HTTPS, if not redirect to HTTPS
});
app.post('/connect', function(req, res){
// Must be on HTTPS
});
app.get('/', function(req, res){
// Must be on HTTP
});
app.get('/build', function(req, res){
// Must be on HTTP
});
Làm sao người ta tạo điều kiện sử dụng cả hai trong cùng một ứng dụng? Tôi đang đấu tranh để tìm thấy bất kỳ ví dụ nào về điều này trong tự nhiên.
Trong trường hợp này, làm thế nào để bạn xử lý các trường hợp mà bạn cần ngăn xếp middleware khác nhau cho các yêu cầu an toàn và không an toàn? Giống như không an toàn, tôi không cần quản lý phiên làm việc trên cao mà cần bảo mật. – Chandu
Cảm ơn điều này rất hữu ích, điều duy nhất ngăn tôi sử dụng HTTPS ở khắp mọi nơi là chi phí, đây là một ứng dụng web hành động chuyên sâu làm cho một số lượng lớn các cuộc gọi API và một cái gì đó như thế này trở nên rất đáng chú ý. Tôi nghĩ nếu người dùng đã xâm phạm hệ thống của riêng họ với phần mềm như vậy thì đó là điều tôi không có trách nhiệm bảo vệ họ. –
@GeorgeReith: Bạn có thực sự đo lường chi phí không? Trên một hệ thống hiện đại, chi phí của SSL là <1% của CPU. Trên thực tế, với các tối ưu hóa như SPDY, bạn có thể thấy rằng kết nối được bảo mật SSL thực sự hoạt động * tốt hơn * so với HTTP thuần túy. Tôi sẵn sàng đặt cược rằng trong thực tế, bạn sẽ không thể nhận thấy ** bất kỳ sự khác biệt tiêu cực nào về hiệu suất. Ngoài ra, việc chiếm đoạt phiên (ăn cắp cookie đăng nhập) là một cuộc tấn công mạng thụ động; nó không liên quan gì đến một máy người dùng bị xâm nhập. (Đây chính là lý do tại sao Facebook là HTTPS bây giờ.) Trong năm 2013, không có lý do gì để không sử dụng tất cả SSL (và HSTS). – josh3736