Tích hợp bản đồ xong, đừng quên giới hạn API key

Việc đầu tiên: mở lại phần Bảo mật của key

Trong trang Quản lý Key, chọn key đang dùng rồi bấm Bảo mật. Ở đây có bốn nhóm: Whitelist domain, Whitelist Wildcard Domain, Whitelist IP và Custom header/mobile ‘T-BUNDLE-ID’.

Không cần thấy có bốn mục là điền đủ cả bốn. Trước hết, hãy xác định ứng dụng gọi API từ đâu: website, máy chủ hay mobile app. Mỗi cách tích hợp sẽ có phần cần chú ý khác nhau.

1. Nếu dùng trên website, bắt đầu từ domain

Ví dụ bản đồ được đặt tại maps.example.com. Trong Whitelist domain, bấm dấu cộng và thêm tên miền này, sau đó bấm Lưu cài đặt.

Cách dễ quản lý nhất là website nào cần dùng thì thêm website đó. Đừng tiện tay mở rộng quyền cho những tên miền chưa có nhu cầu. Sau khi lưu, mở lại website để kiểm tra bản đồ và các chức năng đang tích hợp vẫn hoạt động.

Các tên miền trong bài chỉ để minh họa; khi cấu hình, thay bằng tên miền của bạn và làm theo định dạng của giao diện.

2. Có nhiều subdomain thì cân nhắc wildcard

Giả sử hệ thống có maps.example.com, booking.example.com và một vài website khác cùng tên miền chính. Khai báo từng tên miền sẽ rõ ràng, nhưng khi số lượng tăng lên thì cần quản lý nhiều dòng hơn.

Đó là lúc xem đến Whitelist Wildcard Domain. Giao diện đưa ví dụ *.example.com và mô tả phạm vi gồm domain chính cùng toàn bộ subdomain.

Thuận tiện hơn, nhưng quyền cũng rộng hơn. Nếu chỉ một website cần bản đồ thì chưa có lý do để mở cả nhóm. Đặc biệt, nếu staging cũng nằm dưới example.com, hãy cân nhắc việc dùng wildcard cho key production: bạn có thể vô tình cho cả môi trường thử nghiệm dùng chung key.

Sau khi lưu, thử cả tên miền chính và các subdomain cần dùng để chắc chắn phạm vi hoạt động đúng như dự định.

3. Nếu gọi từ backend, kiểm tra IP đầu ra

Với các tác vụ chạy trên máy chủ, chẳng hạn xử lý địa chỉ hoặc tính tuyến ở backend, hãy xem mục Whitelist IP.

Điểm dễ nhầm ở đây là lấy IP nội bộ của máy rồi nhập vào. Nếu máy chủ đi qua NAT hoặc proxy, dịch vụ API có thể nhìn thấy một IP đầu ra khác. Hãy xác nhận đúng địa chỉ nguồn mà hệ thống thực sự dùng khi gọi ra ngoài.

Cũng đừng lấy IP server website để áp cho mọi yêu cầu từ trang web. Nếu JavaScript trong trình duyệt gọi thẳng đến API, yêu cầu xuất phát từ thiết bị của khách truy cập, không phải server đang lưu website.

Nếu hạ tầng có thể đổi IP sau khi khởi động lại hoặc triển khai, cần chuẩn bị cách giữ IP ổn định hoặc cập nhật danh sách. Nếu không, một lần thay server có thể khiến tích hợp đang chạy bỗng bị từ chối.

4. Với mobile app, chú ý T-BUNDLE-ID

Trong mục Custom header/mobile ‘T-BUNDLE-ID’, khai báo giá trị mà ứng dụng sẽ gửi kèm trong header. Ví dụ trên giao diện là:

T-BUNDLE-ID: 1234567890

Giá trị này chỉ là ví dụ, không phải API key. Phần cấu hình và phần ứng dụng phải khớp nhau; thêm giá trị ở trang quản lý nhưng app không gửi header tương ứng thì chưa đủ.

Một điều cần hiểu đúng: đây là header do client gửi, nên có thể bị sao chép hoặc giả lập. Nó không tự biến thành cơ chế chứng thực ứng dụng tuyệt đối, và cũng không thay thế việc xác thực người dùng hay phân quyền ở backend. Cách gắn header cụ thể cần theo SDK hoặc thư viện gọi API mà app đang sử dụng.

Đừng dùng một key cho mọi môi trường chỉ vì tiện

Khi phát triển, rất hay có cảnh cùng một key được chép vào máy cá nhân, staging, bản demo rồi cuối cùng đi luôn lên production. Lúc cần sửa giới hạn hoặc khóa key, không còn rõ những nơi nào đang phụ thuộc vào nó.

Nếu tài khoản cho phép tạo nhiều key, nên tách ngay từ đầu:

• Dev: dùng để lập trình và thử nghiệm.
• Staging: dùng cho bản kiểm thử trước khi phát hành.
• Production: chỉ dành cho website và ứng dụng đang phục vụ người dùng thật.

Với localhost, nên kiểm tra cách khai báo được hỗ trợ trên key dev riêng, bao gồm hostname và cổng đang dùng. Đừng thấy bản local bị chặn rồi xóa hết giới hạn của key production để “cho chạy trước”. Giải quyết được lỗi trên máy mình nhưng lại mở quyền cho hệ thống thật là một đánh đổi không đáng.

Lưu xong, hãy thử cả trường hợp đáng lẽ phải bị chặn

Kiểm tra website của mình vẫn chạy là cần thiết, nhưng mới được một nửa. Phần còn lại là thử từ nơi không được phép để biết giới hạn có thực sự làm đúng việc hay không.

• Domain đã khai báo có gọi được không? Domain ngoài danh sách có bị từ chối không?
• Nếu giới hạn IP, yêu cầu từ server hợp lệ và từ một nguồn khác có kết quả đúng dự kiến không?
• Nếu dùng T-BUNDLE-ID, khi thiếu hoặc sai header thì phản hồi thế nào?

Khi cấu hình nhiều nhóm cùng lúc, hãy thử từng điều kiện riêng. Đừng tự mặc định chỉ cần khớp một nhóm là được, hoặc bắt buộc phải khớp tất cả. Cách kết hợp cần đối chiếu tài liệu hoặc xác nhận với đội hỗ trợ.

Nếu bản đồ không hiện, mở phần Network trong công cụ dành cho nhà phát triển để xem phản hồi. Không tải được còn có thể do mạng, key hết hạn hoặc lỗi tích hợp, chứ chưa chắc whitelist đã chặn đúng.

Thỉnh thoảng quay lại xem lượng truy vấn

Trang Quản lý Key có biểu đồ theo các nhóm Tiles, Geocoding, Routing và VRP. Khi thấy lưu lượng khác thường, đối chiếu với các thay đổi gần đây: vừa phát hành tính năng mới, tăng người dùng hay có đoạn code gọi lặp?

Lưu lượng tăng chưa đủ để kết luận có người lấy key. Nhưng nếu không giải thích được, đó là lúc kiểm tra lại log, nơi đã chia sẻ key và danh sách được phép.

Giao diện cũng có nút Khóa. Trước khi dùng, nhớ rằng các ứng dụng đang dùng key có thể bị gián đoạn. Xác định nơi bị ảnh hưởng và chuẩn bị phương án xử lý trước. Nếu key đã lộ, che lại trong ảnh chỉ bảo vệ những lần chia sẻ sau, không làm key cũ mất hiệu lực.