Session

Session là một cơ chế giúp lưu trũ thông tin tạm thời giữa các lần truy cập (requests)
của một người dùng cụ thể trong một ứng dụng web. Session thường được dùng để
lưu trũ dữ liệu trong suốt phiên làm việc của người dùng từ khi họ đăng nhập cho đến
khi họ đăng xuất hoặc khi phiên làm việc kết thúc do hết thời gian (timeout)
Cách thức hoạt động của Session
1. Tạo session: Khi một người dùng truy cập vào ứng dụng, một session mới sẽ
được tạo ra. Mỗi session có một ID duy nhất (Session ID) để phân biệt với các
session khác
2. Lưu trữ thông tin: Bạn có thể lưu trữ thông tin tạm thời (như giỏ hàng, lựa chọn
của người dùng, thông tin đăng nhập) vào session. Những dữ liệu này được lưu
phía server, còn phía người dùng (client) chỉ lưu trữ Session ID thông qua cookie
hoặc URL
3. Truy cập lại session: Khi người dùng tiếp tục truy cập các trang khác trong ứng
dụng, session ID của họ được gửi kèm trong mỗi request. Server sẽ sử dụng
session ID này để truy cập thông tin đã lưu trong session và phục vụ người dùng
4. Kết thúc session: Session sẽ tồn tại trong suốt phiên làm việc của người dùng.
Khi người dùng đăng xuất hoặc không tương tác với ứng dụng trong một khoảng
thời gian (timeout), session sẽ bị hủy và các dữ liệu liên quan sẽ không còn nữa
Đặc điểm của Session
Tồn tại trên server: Dữ liệu trong session được lưu trên server, không phải trên
máy khách, giúp bảo mật tốt hơn so với lưu trữ trực tiếp trên trình duyệt
Dùng cho phiên làm việc: Session thường dùng để lưu trữ dữ liệu trong suốt
phiên làm việc ngắn hạn của người dùng. Sau khi người dùng rời khỏi hoặc phiên
kết thúc, dữ liệu sẽ bị mất
Ví dụ về việc sử dụng session
Lưu thông tin đăng nhập: Khi người dùng đăng nhập, thông tin về người dùng
(như username) có thể được lưu vào sesion. Các trang khác sau đó có thể truy
cập session để biết người dùng hiện tại là ai
Giỏ hàng trong trang mua sắm: Khi người dùng thêm sản phẩm vào giỏ hàng,
thông tin giỏ hàng được lưu vào session, và giỏ hàng sẽ được duy trì trong suốt
phiên làm việc
Session giúp quản lý thông tin tạm thời một cách hiệu quả, không cần phải lưu trữ mọi
thông tin người dùng vào cơ sở dữ liệu ngay lập tức

Vấn đề của giao thức HTTP

 Vấn đề chính là HTTP là một giao thức không trạng thái (stateless). Điều này có
nghĩa là, mỗi khi trình duyệt của người dùng gửi một yêu cầu (request) tới server, một
kết nối sẽ được thiết lập, yêu cầu được xử lý và sau đó server gửi lại phản hồi
(response). Sau khi quá trình này kết thúc, kết nối giữa trình duyệt và server sẽ bị
đóng lại, và không có thông tin nào về phiên làm việc trước đó được duy trì.
Việc sử dụng địa chỉ IP để xác định một người dùng cụ thể trên Internet không phải là
giải pháp hiệu quả và không thể đảm bảo tình duy nhất của mỗi người dùng. Trong
một mạng LAN nhiều thiết bị (như máy tính, điện thoại) có thể sử dụng chung một
router để kết nối với Internet. Mặc dù mỗi thiết bị trong mạng nội bộ có địa chỉ IP riêng
(local IP) nhưng khi truy cập Internet, tất cả các thiết bị này sẽ được gán một địa chỉ
IP công cộng chung, chính là địa chỉ IP của router

Việc xác định người dùng và liên kết họ với một phiên làm việc không nhất
thiết phải yêu cầu họ đăng nhập hoặc sử dụng kết nối bảo mật ngay từ đầu

Không bắt buộc đăng nhập sớm:

Theo các nguyên tắc thiết kế web tốt, không nên yêu cầu người dùng đăng nhập
quá sớm. Việc yêu cầu đăng nhập từ đầu có thể gây phiền phức cho người dùng
và làm gián đoạn trải nghiệm duyệt web của họ. Người dùng thường chỉ muốn
đăng nhập khi thực sự cần thiết, ví dụ như khi họ muốn thanh toán hoặc thực
hiện các tác vụ bảo mật.
Trong trường hợp người dùng chỉ đang thêm sản phẩm vào giỏ hàng, không nên
ép họ phải xác thực (đăng nhập) vì điều này có thể khiến họ không muốn tiếp tục
duyệt trang web.
Không bật HTTPS quá sớm:
HTTPS (Hypertext Transfer Protocol Secure) là một giao thức bảo mật, nhưng
việc sử dụng nó cho tất cả các thao tác trên trang web có thể không cần thiết và
tạo ra quá nhiều overhead (tải thêm) cho cả người dùng lẫn server.
Thay vì bật HTTPS cho toàn bộ trang web ngay từ đầu, nhiều trang web chỉ bật
HTTPS ở những phần nhạy cảm như đăng nhập, thanh toán, hoặc xử lý thông
tin cá nhân. Điều này giúp giảm bớt gánh nặng xử lý trên server, đồng thời cải
thiện tốc độ trải nghiệm người dùng.
Liên kết người dùng với session mà không cần xác thực:
Khi người dùng chỉ đang duyệt web và chưa đăng nhập, bạn vẫn cần một cách
để liên kết người dùng với một phiên làm việc (session) mà không yêu cầu
họ phải xác thực (đăng nhập) hoặc sử dụng HTTPS.
Điều này có thể được thực hiện bằng cách sử dụng session ID (thông qua
cookie hoặc URL rewriting), như đã thảo luận trước đó. Đây là cách giúp server
 nhận diện được người dùng và duy trì trạng thái của họ (ví dụ: các mặt hàng
trong giỏ hàng) mà không yêu cầu họ phải đăng nhập.

Cookie

Cookie là một tệp nhỏ mà server tạo ra và gửi đến trình duyệt web của người dùng khi
họ truy cập một trang web. Tệp cookie này sẽ được lưu trữ trên máy tính hoặc thiết bị
của người dùng và được gửi kèm theo mỗi lần người dùng gửi yêu cầu mới đến cùng
một trang web. Cookie được sử dụng để lưu trữ các thông tin quan trọng giúp duy trì
trạng thái phiên làm việc (session), cá nhân hóa trải nghiệm hoặc theo dõi hành vi
người dùng
Các loại Cookie
1. Session cookie (cookie phiên)
Được sử dụng để lưu trữ thông tin tạm thời trong khi người dùng đang duyệt
trang web
Khi người dùng đóng trình duyệt, session cookie sẽ bị xóa
2. Persistent cookie (cookie lâu dài)
Được lưu trữ trên thiết bị của người dùng trong một khoảng thời gian nhất
định (do server quy định)
Những cookie này vẫn tồn tại ngay cả khi trình duyệt đã đóng
Ví dụ: lưu trữ thông tin lâu dài để lần sau người dùng không phải nhập lại
3. Secure cookie (cookie bảo mật)
Chỉ được gửi qua các kết nối bảo mật, chẳng hạn như HTTPS
Được sử dụng để bảo mật thông tin nhạy cảm
4. Third-party cookie (cookie bên thứ ba)
Được tạo ra bởi các trang web khác ngoài trang web mà người dùng đang
truy cập
Thường được sử dụng để theo dõi hành vi người dùng trên nhiều trang web
(ví dụ: quảng cáo)

Code

Lấy Session: HttpSession session = request.getSession()

Kiểm tra Session đã tồn tại hay chưa: if (session.isNew())
request.getSession(boolean)
Khi bạn gọi getSession(true) , nếu không có session hiện tại, nó sẽ tạo một
session mới.
 Khi bạn gọi getSession(false) , nó sẽ không tạo session mới, mà chỉ trả về
session hiện có. Nếu không có session nào tồn tại, nó sẽ trả về null .

URL Rewriting

URL Rewriting là một kỹ thuật được sử dụng trong lập trình web để duy trì thông tin
phiên (session) khi người dùng không cho phép cookie

1. Mục tiêu của URL Rewriting

Mục tiêu của URL Rewriting là cho phép Container (máy chủ ứng dụng) và client
(trình duyệt của người dùng) trao đổi thông tin phiên, cụ thể là session ID. Khi
không thể sử dụng cookie, URL rewriting trở thành phương án thay thế hiệu quả
2. Cách hoạt động của URL Rewriting
Khi một người dùng truy cập vào một trang web mà không hỗ trợ cookie, server
sẽ tạo ra một session ID và thêm nó vào mỗi URL mà trang web gửi tới người
dùng
Ví dụ, nếu một URL thông thường là: http://www.example.com/products
sau khi thêm session ID, nó có thể trở thành: -
http://www.example.com/products?sessionId=123456

Hạn chế của cách sử dụng URL Rewriting

Phải tạo động từng URL: Bạn không thể hard-code session ID vào các trang tĩnh.
Điều này có nghĩa là bạn phải xử lý từng URL trong mã server (ví dụ: servlet) và
đảm bảo rằng session ID được chèn đúng cách vào mọi liên kết
Phải quản lý mọi liên kết: Nếu ứng dụng của bạn có nhiều trang và liên kết, bạn
cần đảm bảo rằng tất cả các liên kết này đều được mã hóa đúng cách. Điều này
có thể làm tăng khối lượng công việc và làm cho mã nguồn trở nên phức tạp hơn
Khó khăn với trang tĩnh: Như đã đề cập, nếu bạn có nhiều trang HTML tĩnh, bạn
không thể dễ dàng thêm session ID vào các liên kết của chúng. Điều này yêu cầu
bạn phải chuyển đổi các trang tĩnh thành trang động hoặc có một cách khác để
tạo ra các trang này trong runtime
Cú pháp: response.encodeRedirectURL("/BeetTest.do")

Leasing

Leasing là một cơ chế thường được sử dụng trong các ứng dụng phân tán để giup
máy chủ quản lý các tài nguyên dành riêng cho từng client. Khi một client kết nối với
 máy chủ và yêu cầu sử dụng tài nguyên, máy chủ cấp cho client một "lease" (hợp
động thuê) với một khoảng thời gian nhất định
Cách hoạt động
1. Client yêu cầu lease: Khi một client kết nối với server, nó yêu cầu một lease để
sử dụng tài nguyên. Server cung cấp cho client một lease, cho phép client sử
dụng tài nguyên trong một khoảng thời gian cố định
2. Client gia hạn: Khi thời gian lease gần hết, client phải gửi yêu cầu gia hạn lease
để cho server biết rằng nó vẫn còn "sống" (alive) và vẫn cần tài nguyên
3. Lease hết hạn: Nếu client không gia hạn lease trước khi nó hết hạn, server hiểu
rằng client đã "biến mất" hoặc không còn cần tài nguyên nữa. Khi đó, server có
thể hủy tài nguyên đã dành riêng cho client này, giúp giải phóng bộ nhớ và các tài
nguyên hệ thống khác

Passivation vs Activation

Session Passivation: Đây là quá trình khi một phiên (session) không còn được sử
dụng trong một thời gian dài, và máy chủ quyết định tạm thời lưu phiên này ra ngoài
bộ nhớ (thường là vào cơ sở dữ liệu hoặc một hệ thống lưu trữ ngoài). Điều này giúp
giảm tải bộ nhớ trên máy chủ. Khi phiên bị passivate, dữ liệu của phiên sẽ không còn
nằm trong bộ nhớ RAM của máy chủ mà được "lưu trữ" (passivated).
Session Activation: Đây là quá trình ngược lại. Khi máy chủ nhận một yêu cầu từ
người dùng và phát hiện phiên đã bị passivate, nó sẽ "kích hoạt" (activate) phiên này
bằng cách tải lại dữ liệu từ nơi lưu trữ (cơ sở dữ liệu hoặc hệ thống lưu trữ ngoài) và
đưa trở lại bộ nhớ RAM của máy chủ.