Các phiên là gì? Họ làm việc như thế nào?


332

Tôi mới bắt đầu học phát triển ứng dụng web, sử dụng python. Tôi bắt gặp các thuật ngữ 'cookie' và 'session'. Tôi hiểu cookie ở chỗ họ lưu trữ một số thông tin trong cặp giá trị chính trên trình duyệt. Nhưng tôi có một chút nhầm lẫn về các phiên, trong một phiên chúng ta cũng lưu trữ dữ liệu trong một cookie trên trình duyệt của người dùng.

Ví dụ: tôi đăng nhập bằng username='rasmus'password='default'. Trong trường hợp như vậy, dữ liệu sẽ được đăng lên máy chủ có nhiệm vụ kiểm tra và đăng nhập cho tôi nếu được xác thực. Tuy nhiên, trong toàn bộ quá trình, máy chủ cũng tạo ID phiên sẽ được lưu trong cookie trên trình duyệt của tôi. Bây giờ máy chủ cũng lưu trữ ID phiên này trong hệ thống tệp hoặc kho dữ liệu của nó.

Nhưng chỉ dựa vào ID phiên, làm thế nào nó có thể biết tên người dùng của tôi trong quá trình truy cập tiếp theo thông qua trang web? Liệu nó có lưu trữ dữ liệu trên máy chủ dưới dạng một lệnh trong đó khóa sẽ là ID phiên và các chi tiết như username, emailv.v. có phải là các giá trị không?

Tôi đang khá bối rối ở đây. Cần giúp đỡ.


9
Có phải nó lưu trữ dữ liệu trên máy chủ dưới dạng một lệnh trong đó khóa sẽ là id phiên và các chi tiết như tên người dùng, email, v.v. ...Đúng. 'Dict' có thể là một cơ sở dữ liệu quan hệ, nhưng về cơ bản nó hoạt động như thế nào.
bobince

14
Tôi muốn hiểu các phiên web quá, bây giờ tôi hiểu. Tôi đã kết thúc việc viết wiki của riêng mình nếu đó là bất kỳ sự giúp đỡ nào: Machinesaredigging.com/2013/10/29/how-does-a-web-session-work
eloone

Trong trường hợp nếu bạn không biết: lưu trữ mật khẩu ở phía máy khách không an toàn, ngay cả khi mật khẩu được băm (thực tế nó không tạo ra sự khác biệt. Cracker có thể nhập trực tiếp mật khẩu băm bằng cách tạo cookie giả) là những cách tốt hơn để lưu trữ trạng thái đăng nhập.
cytsunny

1
Tôi đã tự viết bằng cách sử dụng chi tiết cấp độ giao thức - bitspedia.com/2012/05/ Khăn
Asif Shahzad

Câu trả lời:


400

Vì HTTP không trạng thái, để liên kết một yêu cầu với bất kỳ yêu cầu nào khác, bạn cần một cách để lưu trữ dữ liệu người dùng giữa các yêu cầu HTTP.

Các tham số cookie hoặc URL (ví dụ như http://example.com/myPage?asd=lol&boo=no ) đều là những cách phù hợp để vận chuyển dữ liệu giữa 2 hoặc nhiều yêu cầu. Tuy nhiên, chúng không tốt trong trường hợp bạn không muốn dữ liệu đó có thể đọc / chỉnh sửa được ở phía máy khách.

Giải pháp là lưu trữ phía máy chủ dữ liệu đó, cung cấp cho nó một "id" và cho khách hàng chỉ biết (và gửi lại ở mỗi yêu cầu http) id đó. Có bạn đi, phiên thực hiện. Hoặc bạn có thể sử dụng máy khách như một bộ lưu trữ từ xa tiện lợi, nhưng bạn sẽ mã hóa dữ liệu và giữ bí mật phía máy chủ.

Tất nhiên, có những khía cạnh khác để xem xét, như bạn không muốn mọi người chiếm quyền điều khiển các phiên khác, bạn muốn các phiên không kéo dài mãi mãi mà hết hạn, v.v.

Trong ví dụ cụ thể của bạn, id người dùng (có thể là tên người dùng hoặc ID duy nhất khác trong cơ sở dữ liệu người dùng của bạn) được lưu trữ trong dữ liệu phiên, phía máy chủ, sau khi nhận dạng thành công. Sau đó, với mỗi yêu cầu HTTP bạn nhận được từ máy khách, id phiên (do máy khách cung cấp) sẽ chỉ cho bạn dữ liệu phiên chính xác (được lưu trữ bởi máy chủ) có chứa id người dùng được xác thực - theo cách đó mã của bạn sẽ biết người dùng đó là gì đang nói chuyện với


3
"Bạn không muốn dữ liệu đó được duy trì phía khách hàng". Tại sao không? Nếu bạn sử dụng mật mã mạnh, bạn có thể cho phép khách hàng giữ dữ liệu phiên được mã hóa và lưu trữ trong cookie. Điều này giúp đơn giản hóa đáng kể việc nhân rộng ra nhiều nút vì các máy chủ không cần phải 'nhớ' bất cứ điều gì.
Matt Harrison

5
@MattHarrison bạn sẽ giải mã dữ liệu như thế nào mà không "nhớ bất cứ thứ gì" phía máy chủ? Dù sao, tôi đã cố gắng mở rộng chủ đề này trong câu trả lời của mình.
Luke404

2
@MattHarrison hãy nhớ rằng việc lưu trữ nhiều dữ liệu phía người dùng sẽ tăng lưu lượng truy cập của bạn.
nitsas

5
Không phải bên thứ ba có thể đóng vai trò là người dùng nếu họ có thể chặn khóa phiên của người dùng? Giả sử trang web không sử dụng HTTPS, có vẻ như bên thứ ba có thể giả trang thành người dùng bằng khóa phiên ngay cả khi khóa được mã hóa. Các máy chủ sẽ chỉ giải mã nó.
user137717

2
@ user137717 có, đó là một khả năng nếu bạn cho phép truy cập vào phiên theo nghĩa đen là "mọi người trình bày id phiên chính xác". Có một số hạn chế bạn có thể áp dụng, một trong những hạn chế và phổ biến nhất là lưu trữ IP của máy khách trong phiên: nếu một máy khách từ một ip khác trình bày cùng một id phiên mà bạn đánh dấu là giả mạo và xóa phiên.
Luke404

110

Giải thích đơn giản bằng cách tương tự

Hãy tưởng tượng bạn đang ở trong một ngân hàng, cố gắng lấy một số tiền từ tài khoản của bạn. Nhưng trời tối; ngân hàng tối đen: không có ánh sáng và bạn không thể nhìn thấy bàn tay của mình trước mặt. Bạn được bao quanh bởi 20 người khác. Tất cả đều trông giống nhau. Và mọi người đều có cùng một giọng nói. Và tất cả mọi người là một kẻ xấu tiềm năng. Nói cách khác, HTTP là không trạng thái.

Ngân hàng này là một loại ngân hàng vui nhộn - vì lý do tranh luận ở đây cách mọi thứ hoạt động:

  1. bạn chờ xếp hàng (hoặc trực tuyến) và bạn nói chuyện với người giao dịch: bạn đưa ra yêu cầu rút tiền, và sau đó
  2. bạn phải đợi một lúc trên ghế sofa, và 20 phút sau
  3. bạn phải đi và thực sự thu tiền của bạn từ giao dịch viên.

Nhưng làm thế nào người giao dịch sẽ nói với bạn ngoài những người khác?

Người giao dịch không thể nhìn thấy hoặc dễ dàng nhận ra bạn, hãy nhớ, vì tất cả các đèn đều tắt. Điều gì sẽ xảy ra nếu nhân viên giao dịch của bạn rút 10.000 đô la của bạn cho người khác - người sai?! Điều hết sức quan trọng là người giao dịch có thể nhận ra bạn là người thực hiện rút tiền, để bạn có thể nhận được tiền (hoặc tài nguyên) mà bạn yêu cầu.

Giải pháp:

Khi bạn lần đầu tiên xuất hiện với người giao dịch, anh ấy hoặc cô ấy nói với bạn điều gì đó trong bí mật:

"Khi nào bạn đang nói chuyện với tôi," người giao dịch nói, "trước tiên bạn nên xác định chính mình là GNASHEU329 - theo cách đó tôi biết đó là bạn".

Không ai khác biết mật mã bí mật.

Ví dụ về cách tôi rút tiền mặt:

Vì vậy, tôi quyết định đi đến và thư giãn trong 20 phút và sau đó tôi đến quầy giao dịch và nói "Tôi muốn thu tiền rút tiền của mình"

Người giao dịch hỏi tôi: "anh là ai ??!"

"Là tôi, ông George Banks!"

"Chứng minh đi!"

Và sau đó tôi nói với họ mật mã của mình: GNASHEU329

"Chắc chắn là ông Banks!"

Về cơ bản đó là cách một phiên làm việc. Nó cho phép một người được xác định duy nhất trong một biển hàng triệu người. Bạn cần xác định chính mình mỗi khi bạn giao dịch với người giao dịch.

Nếu bạn có bất kỳ câu hỏi hoặc không rõ ràng - xin vui lòng gửi bình luận và tôi sẽ cố gắng làm rõ nó cho bạn.

Giải thích qua Hình ảnh:

Phiên giải thích qua hình ảnh


9
Thích cách giải thích này - theo cách tương tự của bạn, làm thế nào bạn có thể ngăn chặn các ppl khác nghe lén và cũng nghe được mật mã bí mật mà người giao dịch nói với bạn? Nói cách khác, nếu session_id bị đánh cắp, liệu ai đó có thể bắt chước thông tin đăng nhập của bạn không?
wmock

@wmock chiếm quyền điều khiển phiên chắc chắn là một vấn đề: hãy kiểm tra điều này! owasp.org/index.php/Session_hijacking_attack
BKSpurgeon

2
ví dụ đáng yêu !! nó sẽ được chia sẻ với tâm trí háo hức tìm kiếm học tập!
Victor

trong tương tự của bạn, GNASHEU329là mật khẩu người dùng, tạo ra mã thông báo xác thực hết hạn cho đến một thời điểm nhất định; Sau đó, ông Banks có thể sử dụng mã thông báo xác thực để thực hiện nhiều lần rút tiền liên tiếp mà không phải liên tục đưa mật khẩu cho người giao dịch không?
Daniel Lizik

@DanielLizik bạn def. hiểu khái niệm! Nhưng tôi không đủ hiểu biết về quy trình làm việc dựa trên mã thông báo để cung cấp cho bạn câu trả lời thông minh. Nguyên tắc chung là máy chủ cần có khả năng xác định ai đó là người đưa ra yêu cầu.
BKSpurgeon

39

"Phiên" là thuật ngữ được sử dụng để chỉ thời gian người dùng duyệt trang web. Nó có nghĩa là đại diện cho thời gian giữa lần đầu tiên họ đến một trang trong trang web cho đến khi họ ngừng sử dụng trang web. Trong thực tế, không thể biết khi nào người dùng hoàn thành trang web. Trong hầu hết các máy chủ đều có thời gian chờ tự động kết thúc phiên trừ khi một trang khác được yêu cầu bởi cùng một người dùng.

Lần đầu tiên người dùng kết nối một số loại ID phiên được tạo (cách thực hiện tùy thuộc vào phần mềm máy chủ web và loại xác thực / đăng nhập bạn đang sử dụng trên trang web). Giống như cookie, điều này thường không được gửi trong URL nữa vì đó là vấn đề bảo mật. Thay vào đó, nó được lưu trữ cùng với một loạt các thứ khác mà còn được gọi là phiên. Các biến phiên giống như cookie - chúng là các cặp giá trị tên được gửi cùng với yêu cầu cho một trang và được trả lại cùng với trang từ máy chủ - nhưng tên của chúng được xác định trong một tiêu chuẩn web.

Một số biến phiên được truyền dưới dạng tiêu đề HTTP . Chúng được chuyển qua lại phía sau hậu trường của mỗi trang duyệt để chúng không hiển thị trên trình duyệt và nói với mọi người điều gì đó có thể là riêng tư. Trong số đó có USER_AGENT hoặc loại trình duyệt yêu cầu trang, REAXRER hoặc trang được liên kết đến trang đang được yêu cầu, v.v. Một số phần mềm máy chủ web thêm tiêu đề của riêng họ hoặc chuyển dữ liệu phiên bổ sung cụ thể cho phần mềm máy chủ. Nhưng những tiêu chuẩn là tài liệu khá tốt.

Mong rằng sẽ giúp.


Tôi biết trên các máy chủ IIS tôi sử dụng Tôi có thể lấy tên người dùng từ tiêu đề USER_NAME, nhưng đó có thể là đặc trưng của IIS.
Tim Rourke

REAXRER có nghĩa là gì ở đây?
Gab

@Gab REAXRER thường có nghĩa là một chuỗi tùy ý mà khách hàng gửi trong tiêu đề yêu cầu HTTP "Người giới thiệu". Nó nên chứa URL của tài nguyên mà bạn biết, đã giới thiệu máy khách đến tài nguyên hiện tại.
Luke404

Cảm ơn, nó nên , vì vậy không nhất thiết. vì vậy tôi nghĩ mọi người thường sử dụng tiêu đề này với các ngữ nghĩa khác với đề xuất trong RFC, phải không?
Gab

Đầu tiên bạn viết Like cookies, this usually doesn't get sent in the URL anymorevà sau đó Session variables are like cookies - they're name-value pairs sent along with a request for a page. Điều gì xảy ra chính xác? Có được gửi với lần tiếp theo bạn thực hiện bất kỳ yêu cầu?
KPMG

19

HTTP là giao thức kết nối không trạng thái, nghĩa là máy chủ không thể phân biệt giữa các kết nối khác nhau của những người dùng khác nhau.

Do đó có cookie, một khi máy khách kết nối lần đầu tiên với máy chủ, máy chủ sẽ tạo id phiên mới, sau này sẽ được gửi đến máy khách dưới dạng giá trị cookie. Và kể từ bây giờ, id phiên này sẽ xác định kết nối máy khách đó, bởi vì trong mỗi yêu cầu HTTP, nó sẽ thấy id phiên thích hợp bên trong cookie.

Bây giờ với mỗi id phiên, máy chủ giữ một số cấu trúc dữ liệu, cho phép anh ta lưu trữ dữ liệu cụ thể cho người dùng, cấu trúc dữ liệu này bạn có thể gọi phiên một cách trừu tượng.


1
Bạn có thể làm sáng tỏ hơn về điều này - "Bây giờ với mỗi id phiên, máy chủ giữ một số cấu trúc dữ liệu, cho phép anh ta lưu trữ dữ liệu cụ thể cho người dùng, cấu trúc dữ liệu này bạn có thể gọi phiên một cách trừu tượng."? Máy chủ lưu trữ thông tin cụ thể nào?
realPK

Bạn có thể làm sáng tỏ hơn về điều này - "Bây giờ với mỗi id phiên, máy chủ giữ một số cấu trúc dữ liệu, cho phép anh ta lưu trữ dữ liệu cụ thể cho người dùng, cấu trúc dữ liệu này bạn có thể gọi phiên một cách trừu tượng."? Máy chủ lưu trữ thông tin cụ thể nào?
Gab

Câu hỏi tương tự như trên cũng vậy, nó sẽ hữu ích nếu bạn trả lời.
Suraj Jain

4

Hãy nghĩ về HTTP như một người (A) có MẤT NHIỀU NHỚ NGẮN HẠN và quên mọi người ngay khi người đó khuất mắt.

Bây giờ, để nhớ những người khác nhau, A chụp ảnh người đó và giữ nó. Mỗi bức ảnh của mỗi người có một số ID. Khi người đó xuất hiện trở lại, người đó nói số ID của mình cho A và A tìm thấy hình ảnh của họ bằng số ID. Và voila !!, A biết người đó là ai.

Tương tự với HTTP. Nó đang bị MẤT NHỚ NHỚ NGẮN HẠN. Nó sử dụng Phiên để ghi lại mọi thứ bạn đã làm trong khi sử dụng trang web và sau đó, khi bạn quay lại, nó sẽ xác định bạn với sự trợ giúp của Cookies (Cookie giống như một mã thông báo). Hình ảnh là Phiên ở đây và ID là Cookie ở đây.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.