Xử Lý Phiên (Handling Sessions)
Khi người dùng lần đầu tiên kết nối với Backpack, Backpack sẽ trả về một tham số session đại diện cho kết nối của người dùng. Ở tất cả các phương thức Provider Methodstiếp theo, ứng dụng cần truyền lại tham số session này cho Backpack. Việc lưu trữ tham số session là trách nhiệm của ứng dụng.
Sessions không hết hạn. Sau khi người dùng đã kết nối với Backpack, ứng dụng tương ứng có thể gửi các yêu cầu như SignAndSendTransaction và SignMessage một cách liên tục mà không cần yêu cầu người dùng kết nối lại với Backpack. Tuy nhiên, ứng dụng vẫn cần kết nối lại với Backpack sau khi xảy ra một sự kiện Disconnect hoặc khi gặp phải lỗi Invalid Session.
Cấu Trúc Session
Toàn bộ tham số session được mã hóa bằng base58. Một session sẽ chứa các dữ liệu sau:
JSON Data Signature: Một chữ ký base58 của dữ liệu JSON, có độ dài 64 byte. Backpack sẽ kiểm tra chữ ký này với thông điệp thực tế đã được ký.
JSON Data: Một đối tượng JSON chứa các trường sau:
app_url(string): URL được sử dụng để truy vấn metadata của ứng dụng (ví dụ: tiêu đề, biểu tượng).timestamp(number): Dấu thời gian khi người dùng chấp nhận kết nối. Tại thời điểm này, các phiên không có hạn sử dụng.chain(string): Chuỗi blockchain mà người dùng đã kết nối khi bắt đầu phiên. Một phiên không thể sử dụng cho nhiều chuỗi khác nhau với cùng một keypair. (Ví dụ: người dùng không thể kết nối với Backpack rồi ký giao dịch trên Ethereum.)cluster(string) (optional): Cụm blockchain đã được người dùng và ứng dụng phê duyệt ngay từ đầu.
Giải Mã Sessions
Backpack sẽ tự động giải mã và xác thực tham số session cho mọi yêu cầu gửi đến. Để giải mã phiên, chúng tôi giải mã nó bằng bs58, cắt bỏ 64 byte đầu tiên của chữ ký, và coi phần còn lại là dữ liệu JSON.
Sau đó, chúng tôi ký lại dữ liệu JSON bằng cùng một cặp khóa và so sánh chữ ký đó với chữ ký trong phiên. Nếu chữ ký trùng khớp, phiên là hợp lệ. Nếu không, chúng tôi kết luận phiên đã bị giả mạo vì chữ ký không thuộc về cặp khóa mà nó tuyên bố.
Gọi nacl.sign.open sẽ thuận tiện xác minh và trả về đối tượng gốc. Để biết thêm thông tin, vui lòng tham khảo Encryption Resources.
Sau khi chúng tôi xác định phiên hợp lệ, chúng tôi vẫn cần đảm bảo các trường JSON khớp với những gì mong đợi. Một ứng dụng có thể cung cấp một phiên thuộc pubkey A rong khi người dùng hiện đang sử dụng pubkey B trong Backpack.
Trong trường hợp đó, phiên đó sẽ không được phép để ứng dụng yêu cầu chữ ký. Thay vào đó, ứng dụng phải thực hiện một yêu cầu kết nối mới hoặc sử dụng đúng phiên.
// Encoding a session
const privateKey = ...;
const sessionData = JSON.stringify({
"app_id": "APP_ID",
"chain": "CHAIN",
"cluster": "CLUSTER",
"timestamp": 1644954984,
});
const bytes = Buffer.from(sessionData, "utf-8");
// tweetnacl-js formats signature in format <signature><sessionData>
const signature = bs58.encode(nacl.sign(bytes, privateKey));
// Decoding ja session
const publicKey = ...;
const verifiedSessionData = nacl.sign.open(bs58.decode(signature), publicKey.toBytes());
if (!verifiedSessionData) throw new Error(`This session was not signed by ${publicKey}`);Sessions Không Hợp Lệ
Mặc dù các session không hết hạn, vẫn có một số lý do khiến session bị coi là không hợp lệ:
Nó không được ký bởi cặp khóa ví hiện tại. Điều này có thể có nghĩa là phiên hoàn toàn giả mạo, hoặc nó được ký bởi một cặp khóa khác trong ví của người dùng.
Nó được ký bởi cặp khóa ví hiện tại, nhưng
dataJSON của session không hợp lệ. Có một vài lý do khiến điều này có thể xảy ra:Người dùng đã chuyển đổi chuỗi (hoặc có thể là mạng).
app_urlcó thể bị chặn nếu độc hại.
Last updated