AWS SigV4 khi URL bị rewrite: so canonical request hai đầu

AWS SigV4 khi URL bị rewrite là tình huống request đã ký đúng ở client nhưng tới nơi thì bị báo chữ ký không khớp, vì một reverse proxy giữa đường đã đổi host, đường dẫn hay cách mã hóa. Cách chẩn đoán nhanh nhất là dựng canonical request ở cả hai đầu rồi so từng dòng. ProxyVN ký request bằng botocore thật, cho đi qua một reverse proxy lab có chín kiểu viết lại, dựng lại canonical request ở origin và chỉ ra dòng nào lệch trong từng ca.

AWS SigV4 khi URL bị rewrite: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và giới hạn.

Bài toán cần giải

Một nhóm gọi API nội bộ được bảo vệ bằng SigV4, qua một tên miền công khai có reverse proxy đứng trước. Gọi thẳng thì chạy. Gọi qua tên miền công khai thì nhận lỗi chữ ký không khớp. Không ai biết proxy đổi gì, vì log của proxy chỉ ghi đường dẫn đầu vào.

Đầu ra nghiệm thu

Đầu ra là canonical request của client đã che credential, đặt cạnh canonical request mà origin dựng lại, cho từng ca viết lại. Mỗi ca có mã trạng thái và danh sách dòng canonical khác nhau. Ca đi qua mà không viết lại là ca đối chứng.

Ranh giới với bài AWS CLI proxy

Bài AWS CLI proxy nói về cấu hình đường đi: biến môi trường, chứng chỉ, forward proxy cho AWS CLI. Bài này không bàn cấu hình CLI hay cách đặt credential. Ở đây proxy là reverse proxy viết lại request, và câu hỏi là chữ ký còn đúng không.

Ranh giới với HTTP Message Signatures

Bài HTTP Message Signatures trong cụm này dùng chuẩn RFC 9421, chọn được thành phần nào được ký. SigV4 là giao thức riêng của AWS, có quy tắc canonical cố định: sắp xếp query, mã hóa đường dẫn, danh sách header bắt buộc. Một số thay đổi làm hỏng RFC 9421 lại không làm hỏng SigV4, và ngược lại.

Giới hạn của lab

Nói rõ ngay. Lab không gọi AWS. Client ký bằng botocore 1.43.124 thật với credential giả. Origin là máy chủ lab tự tính lại chữ ký bằng chính botocore với cùng secret, mô phỏng việc AWS kiểm tra. Reverse proxy là máy chủ Python tự viết.

Thứ gì tin được

Cách botocore dựng canonical request và tính chữ ký là thật. Cách origin lab kiểm là cùng thuật toán, nên mọi lệch đều do request bị đổi. Thứ chưa chắc là AWS có chuẩn hóa thêm bước nào ở phía máy chủ mà botocore không làm, bài ghi rõ ở từng ca.

Ai nên đọc bài này

Người đặt API Gateway, Lambda URL, OpenSearch hay dịch vụ ký SigV4 khác sau reverse proxy của mình. Người vận hành nginx, Envoy hay proxy doanh nghiệp đứng giữa ứng dụng và AWS. Người đang nhìn lỗi chữ ký không khớp và cần biết bắt đầu từ đâu.

AWS SigV4 khi URL bị rewrite: chẩn đoán canonical request khi reverse proxy đổi host và path

Phần này tóm tắt tài liệu chính thức về canonical request.

SigV4 làm gì

Trang AWS Signature Version 4 for API requests mô tả SigV4 là giao thức ký của AWS. Ký gồm ba bước: dựng canonical request từ chi tiết request, tính chữ ký bằng credential, thêm chữ ký vào header Authorization. AWS lặp lại đúng quy trình đó để kiểm, rồi cho phép hoặc từ chối.

Sáu dòng của canonical request

Trang tạo request đã ký nêu canonical request gồm sáu phần nối bằng xuống dòng: phương thức, canonical URI, canonical query string, canonical headers, signed headers, hashed payload. Mỗi phần có quy tắc riêng.

Bảng: Sáu dòng của canonical request

Dòng	Nội dung	Proxy hay đổi không
HTTPMethod	GET, POST	Hiếm
CanonicalURI	Đường dẫn đã mã hóa	Hay đổi
CanonicalQueryString	Query đã mã hóa, sắp theo tên	Đổi thứ tự không sao
CanonicalHeaders	Header được ký, chữ thường, cắt khoảng trắng	Host, Content-Type hay đổi
SignedHeaders	Danh sách tên header được ký
HashedPayload	SHA-256 của body	Đổi khi sửa body

Canonical URI

Tài liệu nêu canonical URI là phiên bản đã mã hóa của đường dẫn tính từ gốc, bắt đầu từ dấu gạch chéo sau tên miền, tới hết chuỗi hoặc tới dấu hỏi. Đường dẫn rỗng thì dùng một dấu gạch chéo. Dấu gạch chéo trong đường dẫn không bị mã hóa.

Canonical query string

Tài liệu nêu mã hóa từng tên và giá trị riêng rẽ, rồi sắp xếp theo tên khóa, việc sắp xếp làm sau khi mã hóa. Hệ quả: đổi thứ tự tham số không làm đổi canonical query. Lab sẽ xác nhận điều này.

Canonical headers

Tài liệu nêu mỗi header là tên viết thường, dấu hai chấm, giá trị đã cắt khoảng trắng hai đầu. Danh sách bắt buộc có Host. Nếu request có Content-Type thì phải đưa vào. Mọi header bắt đầu bằng x-amz định gửi cũng phải đưa vào.

Host luôn được ký

Vì Host bắt buộc nằm trong canonical headers, mọi proxy đổi Host đều làm chữ ký hỏng. Đây là nguồn lỗi phổ biến nhất khi đặt dịch vụ AWS sau reverse proxy: proxy chuyển Host sang tên nội bộ hoặc tên của dịch vụ đích.

Lỗi trả về

Khi chữ ký không khớp, AWS trả lỗi SignatureDoesNotMatch với thông báo quen thuộc rằng chữ ký AWS tính ra không khớp chữ ký gửi lên. Origin lab trả đúng mã và câu này để mô phỏng. Lỗi không nói dòng nào lệch, đó là lý do phải tự so canonical.

AWS SigV4 khi URL bị rewrite: tạo canonical request đã che credential

Phần này ký request và in canonical request an toàn để chia sẻ.

Credential giả

Lab dùng access key và secret giả, không phải của tài khoản nào.

from botocore.credentials import Credentials
CRED = Credentials("AKIALABEXAMPLE000001", "lab-secret-khong-phai-that/abc123")
REGION, SERVICE = "ap-southeast-1", "execute-api"

Dịch vụ execute-api là API Gateway. Vùng ap-southeast-1 là Singapore. Cả hai chỉ dùng để dựng chuỗi phạm vi, lab không gọi AWS.

Ký request

Botocore ký một AWSRequest và thêm header Authorization cùng X-Amz-Date.

from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
 
r = AWSRequest(method="GET", url=PUB)
SigV4Auth(CRED, SERVICE, REGION).add_auth(r)

Địa chỉ công khai của lab là cổng 9492 với tiền tố prod, đường dẫn items có tên sản phẩm chứa dấu cách và dấu hai chấm đã mã hóa.

Canonical request của client

Canonical đã che

Output thật của lab, đã che access key.

GET
/prod/items/ban%2520phim%253Aco
day=2026-11-05&shop=a
host:127.0.0.1:9492
x-amz-date:20261105T075653Z
 
host;x-amz-date
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Dòng cuối là SHA-256 của body rỗng. Thấy chuỗi e3b0c442 là biết request không có body.

Đường dẫn bị mã hóa hai lần

Đường dẫn gửi đi là ban%20phim%3Aco. Canonical URI là ban%2520phim%253Aco: dấu phần trăm đã bị mã hóa thành %25. Botocore mã hóa đường dẫn hai lần cho dịch vụ không phải S3. Ai tự viết bộ ký mà chỉ mã hóa một lần sẽ không khớp với AWS.

Query đã sắp xếp

Query gửi đi là shop trước, day sau. Canonical query là day trước, shop sau, theo thứ tự chữ cái của tên khóa. Đúng như tài liệu mô tả.

Che credential trước khi chia sẻ

Canonical request không chứa secret, nhưng header Authorization chứa access key và phạm vi. Trước khi dán vào phiếu hỗ trợ hay gửi cho người khác, che access key. Lab dùng một biểu thức chính quy thay chuỗi AKIA và mười sáu ký tự sau nó.

mask = lambda s: re.sub(r"AKIA[A-Z0-9]{16}", "AKIA****", s)

Header Authorization sau khi che: Credential bằng AKIA bốn sao, ngày, vùng, dịch vụ, aws4_request, rồi SignedHeaders và Signature.

Không bao giờ in secret

Secret access key không xuất hiện trong canonical request, string to sign hay header. Nó chỉ dùng để tính khóa ký. Mã gỡ lỗi in credential object là cách nhanh nhất làm lộ secret. Lab chỉ in canonical request và header đã che.

AWS SigV4 khi URL bị rewrite: ghi host, path và query tại client và origin

Phần này dựng origin và cách so hai bản canonical.

Origin dựng lại canonical

Origin đọc SignedHeaders trong Authorization, lấy đúng các header đó từ request nhận được, dựng AWSRequest với Host nhận được và đường dẫn nhận được, đặt cùng timestamp X-Amz-Date, rồi tính canonical, string to sign và chữ ký.

r = AWSRequest(method=self.command, url="http://" + self.headers["Host"] + self.path,
               data=body, headers={h: self.headers[h] for h in signed})
r.context["timestamp"] = self.headers["X-Amz-Date"]
cr = a.canonical_request(r); mine = a.signature(a.string_to_sign(r, cr), r)

So mine với Signature trong header. Khác thì trả 403 SignatureDoesNotMatch.

Cùng timestamp ở hai đầu

Origin đặt timestamp bằng giá trị X-Amz-Date nhận được trước khi dựng canonical. Nếu để botocore lấy giờ hiện tại, dòng x-amz-date và chuỗi phạm vi sẽ khác, mọi ca đều lệch. AWS cũng dùng X-Amz-Date của request, kèm kiểm khoảng lệch cho phép.

So từng dòng

Client lưu canonical của mình, origin lưu canonical dựng lại. Mã lab so hai bản theo từng dòng và in dòng khác nhau. Với AWS thật, origin là AWS và không trả canonical. Một số dịch vụ có trả canonical AWS dựng được trong thông báo lỗi chi tiết, nhưng không phải dịch vụ nào cũng có.

Ca C1: qua proxy không sửa

Reverse proxy chuyển nguyên phương thức, đường dẫn, Host và header. Origin dựng ra cùng canonical, chữ ký khớp.

== C1 qua reverse proxy khong sua: 200 OK | dong canonical khac: []

Ca đối chứng. Nếu C1 không qua, lỗi nằm ở bộ ký hay đồng hồ, chưa phải ở proxy. Trong lab, hai bản canonical giống nhau từng ký tự, kể cả dòng mã băm body rỗng.

Ca C2: proxy thêm header

Proxy thêm Via và X-Forwarded-For. Hai header không nằm trong SignedHeaders, canonical không đổi, chữ ký khớp. Proxy được phép thêm header không ký.

Thứ tự chạy các ca

Chạy C1 trước, rồi C2, rồi mới tới các ca có viết lại. Nếu C1 không qua mà C11 qua, lỗi nằm ở cách proxy chuyển request dù chưa cấu hình viết lại gì. Nếu cả hai không qua, lỗi nằm ở client hoặc origin, chưa liên quan proxy.

Ca C11: gọi thẳng địa chỉ nội bộ

Client ký với địa chỉ nội bộ cổng 9493 không có tiền tố và gọi thẳng. Chữ ký khớp. Ca này xác nhận origin lab kiểm đúng, và cho thấy cùng request ký theo địa chỉ khác là chữ ký khác.

Ghi log đúng chỗ

Log của proxy nên ghi cả đường dẫn và Host đầu vào lẫn đầu ra. Log của client nên ghi canonical request đã che. Hai log này đủ để tái lập mọi ca trong bài mà không cần log của AWS.

AWS SigV4 khi URL bị rewrite: tái lập proxy rewrite một thành phần canonical

Phần này chạy từng kiểu viết lại và chỉ ra dòng lệch.

Ca C3: bỏ tiền tố stage

Bỏ tiền tố stage

Reverse proxy bỏ tiền tố prod khỏi đường dẫn trước khi chuyển vào trong. Dòng canonical URI khác.

== C3 proxy bo tien to /prod (stage): 403 SignatureDoesNotMatch
   dong canonical khac: [(1, '/prod/items/ban%2520phim%253Aco', '/items/ban%2520phim%253Aco')]

Dòng số 1 là canonical URI. Đây là kiểu viết lại phổ biến khi API có tiền tố stage hay phiên bản.

Ca C4: đổi Host

Proxy đổi Host sang địa chỉ nội bộ. Dòng canonical headers chứa host khác.

== C4 proxy doi Host sang noi bo: 403 SignatureDoesNotMatch
   dong canonical khac: [(3, 'host:127.0.0.1:9492', 'host:127.0.0.1:9493')]

Nhiều reverse proxy mặc định đặt Host bằng địa chỉ của upstream. Phải cấu hình giữ Host gốc, hoặc client ký theo Host mà upstream sẽ thấy.

Ca C5: đảo thứ tự query

Proxy đảo thứ tự hai tham số. Canonical query vẫn là day rồi shop sau khi sắp xếp, chữ ký khớp.

== C5 proxy dao thu tu query: 200 OK | dong canonical khac: []

Khác với RFC 9421, nơi ký nguyên chuỗi query thì đảo thứ tự là hỏng.

Ca C6: đổi %20 thành dấu cộng

Proxy viết lại dấu cách đã mã hóa thành dấu cộng. Với đường dẫn, dấu cộng là ký tự cộng, không phải dấu cách. Canonical URI thành ban%2Bphim, khác ban%2520phim.

== C6 proxy doi %20 thanh +: 403 SignatureDoesNotMatch

Ca C7: giải mã %3A

Proxy giải mã %3A thành dấu hai chấm trong đường dẫn. Canonical URI đổi từ %253A thành %3A. Một proxy chuẩn hóa URL với ý tốt là đủ làm hỏng chữ ký.

Ca C8: thêm dấu gạch chéo

Proxy chèn thêm một dấu gạch chéo trước items, thành hai dấu liền nhau. Chữ ký vẫn khớp.

== C8 proxy gop/them dau / trong path: 200 OK | dong canonical khac: []

Botocore ở origin lab chuẩn hóa đường dẫn, gộp đoạn rỗng, nên canonical giống bản gốc. AWS thật có chuẩn hóa giống vậy hay không với từng dịch vụ, lab không kiểm được. Với S3, đường dẫn thường không được chuẩn hóa.

Ca C9: thêm charset vào Content-Type

Request POST có body JSON và Content-Type application/json. Botocore đưa content-type vào SignedHeaders. Proxy thêm charset utf-8. Dòng content-type trong canonical khác.

== C9 ...: 403 SignatureDoesNotMatch
   dong canonical khac: [(3, 'content-type:application/json', 'content-type:application/json; charset=utf-8')]

Ca C10 cùng request, proxy không sửa, chữ ký khớp với mã 200.

AWS SigV4 khi URL bị rewrite: so signature mismatch với ca đi qua không rewrite

Phần này gom bảng kết quả, tài sản chính của bài.

Bảng kết quả

Bảng mười một ca

Bảng dưới là đầu ra nghiệm thu, gom từ output thật.

Bảng: Bảng kết quả

Ca	Proxy làm gì	Mã	Dòng canonical lệch
C1	Không sửa	200	Không
C2	Thêm Via, X-Forwarded-For	200	Không
C3	Bỏ tiền tố prod	403	CanonicalURI
C4	Đổi Host sang nội bộ	403	CanonicalHeaders host
C5	Đảo thứ tự query	200	Không
C6	%20 thành dấu cộng	403	CanonicalURI
C7	Giải mã %3A	403	CanonicalURI
C8	Thêm dấu gạch chéo	200	Không, do chuẩn hóa
C9	Thêm charset Content-Type	403	CanonicalHeaders content-type
C10	POST không sửa	200	Không
C11	Gọi thẳng địa chỉ nội bộ	200	Không

Ba nhóm lỗi

Lệch đường dẫn: bỏ tiền tố, đổi mã hóa, giải mã ký tự. Lệch header: đổi Host, đổi Content-Type. Không lệch: thêm header không ký, đảo query, thêm gạch chéo thừa. Khi gặp lỗi chữ ký, kiểm nhóm đường dẫn trước, vì đó là nhóm proxy hay đụng nhất.

Cách đọc một ca lỗi

So dòng 1 trước: canonical URI. Rồi dòng 3 trở đi: host và các header được ký. Dòng 2 hiếm khi lệch vì query được sắp xếp. Dòng cuối lệch nghĩa là body bị đổi. Bốn bước này khoanh vùng phần lớn trường hợp.

Cách sửa từng nhóm

Bỏ tiền tố: client ký theo đường dẫn mà upstream sẽ thấy, hoặc proxy không bỏ tiền tố. Đổi Host: proxy giữ Host gốc, hoặc client ký theo Host của upstream. Đổi mã hóa: tắt chuẩn hóa URL của proxy cho tuyến này. Đổi Content-Type: proxy không chạm vào header được ký.

Ký theo địa chỉ của upstream

Ca C11 cho thấy ký theo địa chỉ nội bộ thì khớp. Với API Gateway, client thường ký theo tên miền của API Gateway, và reverse proxy phải chuyển Host đó nguyên vẹn. Nếu proxy bắt buộc đổi Host, client phải ký theo Host sau khi đổi, tức client cần biết cấu hình proxy.

Proxy ký lại

Một lựa chọn khác: proxy nhận request không ký hoặc ký theo cơ chế khác, rồi tự ký SigV4 bằng credential của chính nó khi chuyển vào AWS. Cách này đưa credential vào proxy, nên chỉ dùng khi proxy là thành phần tin cậy của hệ thống. Lab không thử.

Thử từng thay đổi một

Khi proxy thật làm nhiều việc cùng lúc, tắt từng tính năng rồi chạy lại ca C1. Tính năng nào tắt đi mà lỗi biến mất là thủ phạm. Lab tách mỗi kiểu viết lại thành một ca riêng vì lý do này: một lần chỉ đổi một thứ, nên dòng lệch trỏ thẳng vào nguyên nhân.

Đừng sửa bằng cách bỏ ký header

Có người sửa ca C9 bằng cách không ký Content-Type. Tài liệu nêu Content-Type có mặt thì phải đưa vào canonical headers, nên cách này không hợp lệ với AWS. Sửa ở proxy, không sửa ở danh sách ký.

Kiểm đồng hồ

Lỗi chữ ký đôi khi không do proxy mà do đồng hồ. X-Amz-Date lệch quá xa giờ của AWS sẽ bị từ chối, với mã lỗi khác. Origin lab dùng đúng X-Amz-Date nhận được nên không kiểm lệch giờ. Trên hệ thật, đồng bộ thời gian máy client trước khi nghi proxy.

AWS SigV4 khi URL bị rewrite: cấu hình reverse proxy cho đúng

Phần này dành cho người vận hành proxy.

Giữ nguyên đường dẫn

Cấu hình proxy đúng

Cấu hình chuyển đường dẫn nguyên văn, không giải mã rồi mã hóa lại. Nhiều proxy có tùy chọn chuyển URI gốc thay vì URI đã chuẩn hóa. Chọn tùy chọn đó cho tuyến dẫn tới dịch vụ ký SigV4. Ca C6 và C7 là test cho cấu hình này.

Giữ nguyên Host

Cấu hình chuyển Host gốc của client thay vì Host của upstream. Nếu upstream yêu cầu Host riêng, như API Gateway với tên miền mặc định, cân nhắc dùng tên miền tùy chỉnh ở API Gateway để Host công khai và Host của upstream là một.

Không chạm header được ký

Danh sách header được ký nằm trong SignedHeaders của từng request. Với request có body, Content-Type gần như luôn có mặt. Proxy không thêm charset, không đổi chữ hoa thường của giá trị. Proxy được thêm header mới như Via.

Tiền tố đường dẫn

Nếu cần tiền tố công khai khác upstream, có hai cách. Đặt cùng tiền tố ở upstream để proxy không phải bỏ. Hoặc để client biết đường dẫn thật và ký theo đó. Cách đầu ít rắc rối hơn cho client.

Bộ test cho proxy

Mười một ca của lab là bộ test tối thiểu. Thay reverse proxy lab bằng proxy thật, trỏ origin lab vào sau proxy, chạy lại. Ca nào khác bảng trong bài là chỗ proxy thật đang viết lại request.

Log hai đầu

Bật log ở proxy ghi đường dẫn, query và Host cả đầu vào lẫn đầu ra cho tuyến SigV4. Không ghi header Authorization. Log này đủ để đối chiếu với canonical của client khi có lỗi.

AWS SigV4 khi URL bị rewrite: những trường hợp hay gặp trong thực tế

Phần này nối các ca lab với vài kiến trúc anh em hay dựng quanh dịch vụ AWS.

API Gateway sau CDN

Một CDN đặt trước API Gateway thường đổi Host sang tên miền mặc định của API Gateway khi chuyển vào. Client ký theo tên miền công khai sẽ gặp đúng ca C4. Cách hay dùng là đặt tên miền tùy chỉnh trên API Gateway trùng với tên miền công khai, để Host không phải đổi.

Tiền tố stage

API Gateway REST có tên stage nằm trong đường dẫn, như prod trong lab. Khi gắn tên miền tùy chỉnh, stage có thể được ánh xạ để đường dẫn công khai không còn tiền tố. Client ký theo đường dẫn mà nó gửi tới tên miền tùy chỉnh. Nếu một proxy nữa ở giữa bỏ hoặc thêm tiền tố, đó là ca C3.

OpenSearch sau nginx

Nhiều nhóm đặt nginx trước miền OpenSearch để thêm đăng nhập hay giới hạn IP. Nginx mặc định có thể chuẩn hóa URI và đặt Host theo upstream. Với request ký SigV4 từ client, cả hai mặc định đều gây lỗi. Hoặc cấu hình giữ nguyên, hoặc để nginx tự ký bằng credential của nó.

Tên chứa ký tự đặc biệt

Dữ liệu crawl hay có tên sản phẩm chứa dấu cách, dấu hai chấm, ký tự tiếng Việt. Đưa những tên này vào đường dẫn API là mời ca C6 và C7. Nếu được, đưa giá trị vào query hoặc body thay vì đường dẫn. Query được mã hóa theo quy tắc rõ ràng và sắp xếp, ít bị proxy đụng hơn.

Ký tự tiếng Việt

Ký tự có dấu được mã hóa UTF-8 rồi phần trăm. Proxy giải mã để ghi log rồi mã hóa lại theo cách khác, như chữ hoa thường của mã hex, là lệch. Lab không thử ký tự tiếng Việt, nhưng cơ chế giống ca C7. Đặt một ca như vậy vào bộ test nếu API nhận tên tiếng Việt.

Body lớn và payload không ký

Với body lớn, một số dịch vụ cho phép dùng giá trị đặc biệt thay cho mã băm body. Lab không thử. Nếu dùng, dòng cuối của canonical không còn là mã băm thật, và proxy sửa body sẽ không bị phát hiện qua chữ ký. Cân nhắc kỹ trước khi dùng qua proxy không tin cậy.

Thư viện khác botocore

SDK của ngôn ngữ khác cũng ký SigV4, nhưng chi tiết mã hóa đường dẫn có thể khác ở các trường hợp biên. Khi một client viết bằng ngôn ngữ khác bị lỗi chữ ký mà client Python thì không, so canonical của hai client với cùng request trước khi nghi proxy.

Ghi canonical vào log có kiểm soát

Bật in canonical chỉ khi gỡ lỗi, không bật thường trực. Canonical chứa đường dẫn và query, có thể chứa dữ liệu nhạy cảm của người dùng. Che access key, giữ log trong thời gian ngắn, xóa sau khi xong việc.

AWS SigV4 khi URL bị rewrite: đầu ra nghiệm thu và phần chưa chạy

Phần này gom tiêu chí đạt, tệp đầu ra và những gì còn phải kiểm.

Danh sách kiểm tra

Hệ thống đạt khi mọi dòng dưới đây đúng.

• Client in được canonical request đã che credential khi cần gỡ lỗi.
• Ca đi thẳng và ca qua proxy không sửa đều qua.
• Proxy giữ nguyên đường dẫn, không giải mã hay mã hóa lại.
• Proxy giữ nguyên Host, hoặc client ký theo Host của upstream.
• Proxy không chạm Content-Type và header x-amz.
• Tiền tố đường dẫn thống nhất giữa công khai và upstream.
• Đồng hồ máy client đã đồng bộ.
• Có bộ test mười một ca chạy lại khi đổi cấu hình proxy.

Tệp đầu ra của lab

Lab có run.py chứa reverse proxy, origin và mười một ca. Output in canonical của client đã che, header Authorization đã che, mã trạng thái và dòng canonical lệch cho mỗi ca. Chạy lại mất vài giây.

Những gì lab chưa chạy

Chưa gọi AWS thật, chưa thử S3 với quy tắc mã hóa một lần, chưa thử SigV4A, chưa thử body lớn hay ký với payload không ký, chưa thử proxy thật như nginx hay Envoy. Hành vi chuẩn hóa đường dẫn ở ca C8 là của botocore trong vai origin.

Kiểm lại với AWS

Dùng một API thử với credential thử, gọi thẳng và gọi qua proxy. Nếu qua proxy bị SignatureDoesNotMatch, so canonical của client với log đầu ra của proxy theo bảng trong bài.

Proxy ở đâu trong luồng này

Bài nói về reverse proxy phía máy chủ. Forward proxy phía client, dạng CONNECT, không chạm vào request nên không làm hỏng chữ ký. Với API được phép truy cập, khi cần IP Việt Nam ổn định cho phía client, anh em có thể mua proxy tại trang chủ ProxyVN. Vai trò proxy có ở bài Web Scraping proxy là gì, cách ghi chuỗi proxy ở bài định dạng proxy.

AWS SigV4 khi URL bị rewrite: câu hỏi thường gặp

Các câu dưới đây gom những điểm anh em hay hỏi.

Proxy thêm header có làm hỏng SigV4 không?

Không, nếu header đó không nằm trong SignedHeaders. Ca C2 thêm Via và X-Forwarded-For, chữ ký vẫn khớp.

Đảo thứ tự query có sao không?

Không. Canonical query được sắp xếp theo tên khóa. Ca C5 đảo thứ tự vẫn qua.

Vì sao bỏ tiền tố đường dẫn lại hỏng?

Vì canonical URI là đường dẫn đầy đủ. Ca C3 bỏ prod làm dòng canonical URI lệch.

Đổi Host sang nội bộ có được không?

Không, trừ khi client ký theo Host nội bộ. Host luôn nằm trong canonical headers, ca C4 cho thấy lệch ngay.

Làm sao chia sẻ canonical request an toàn?

Che access key trong header Authorization, không in secret. Canonical request tự nó không chứa secret.

Lỗi chữ ký có phải do credential sai không?

Có thể. Credential sai cũng cho SignatureDoesNotMatch hoặc lỗi khóa không hợp lệ. Chạy ca C1 gọi thẳng trước: qua thì credential đúng, lỗi nằm ở đường đi.

Vì sao canonical có %2520 thay vì %20?

Botocore mã hóa đường dẫn hai lần với dịch vụ không phải S3, nên dấu phần trăm thành %25. Bộ ký tự viết chỉ mã hóa một lần sẽ lệch với botocore.

Proxy có cần biết secret không?

Không, nếu proxy chỉ chuyển request. Chỉ khi proxy tự ký lại thay client thì mới cần credential riêng của nó.

Có test được mà không cần AWS không?

Có, như lab. Origin tự tính lại chữ ký bằng botocore với cùng secret giả. Cách này kiểm được proxy, không kiểm được chuẩn hóa riêng của dịch vụ AWS.

Bài có gọi AWS không?

Không. Client ký bằng botocore thật, origin lab kiểm bằng cùng thuật toán. Chuẩn hóa phía máy chủ AWS cần kiểm với dịch vụ cụ thể.

AWS SigV4 khi URL bị rewrite và những điều cần nhớ

AWS SigV4 khi URL bị rewrite chỉ cần so canonical request ở hai đầu là biết proxy đổi gì: đường dẫn, Host hay header được ký. Hãy giữ nguyên đường dẫn và Host qua proxy, che credential khi chia sẻ, chạy bộ ca test mỗi khi đổi cấu hình. Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khuyên anh em chạy thử AWS SigV4 khi URL bị rewrite với API thử trước.