Làm cách nào tôi có thể tự động nhận mã thông báo mang?
Một số nhà phát triển gặp phải sự cố nhỏ này khi kiểm tra API REST, họ cần tìm nạp và đính kèm mã thông báo mang để thực hiện kiểm tra API REST mỗi khi mã thông báo hết hạn. Vì vậy, đây là giải pháp để tránh lặp lại cùng một quy trình tìm nạp và đính kèm mã thông báo mang Show Tất cả những gì bạn cần để viết một vài dòng mã trong tập lệnh yêu cầu trước trong bộ sưu tập yêu cầu. Trong hướng dẫn này, bạn sẽ tìm hiểu cách sử dụng tập lệnh yêu cầu trước để tìm nạp và đính kèm mã thông báo mang để giúp kiểm tra API REST của bạn dễ dàng hơn, hãy xem ví dụ bên dưới Trong bài viết này, tôi trình bày cách thiết lập bộ sưu tập người đưa thư để tự động bao gồm mã thông báo ủy quyền khi thực hiện yêu cầu tới các điểm cuối được bảo mật Chỉnh sửa bộ sưu tậpThứ nhất, tôi giả sử bạn đã tạo một bộ sưu tập. Tôi đã tạo một cái gọi là phương tiện. Tiếp theo chúng ta tiến hành chỉnh sửa bộ sưu tập này. Điều này sẽ đưa chúng ta đến phần này của người đưa thư Để thực hiện một yêu cầu Http mới như 3, 4, 5, 6 hoặc 7, chỉ cần nhấp vào biểu tượng 8 như được tô sáng từ ảnh chụp màn hình trước đó. Sau đó, bạn sẽ thấy màn hình sauTrong ảnh chụp màn hình trước, tôi đã đánh dấu hai trường cơ bản để cung cấp. Đầu tiên là danh sách thả xuống Động từ http. Từ đó, bạn có thể chọn hành động để thực hiện. Theo mặc định, nó mặc định là 3. Trường thứ hai là điểm cuối API mà bạn muốn kiểm tra. Hãy dùng thử và thực hiện yêu cầu 3 tới Bored API. Phần sau hiển thị phản hồi sau khi nhấp vào nút "Gửi"Bạn thấy đấy, làm thế nào chúng ta có thể dễ dàng tương tác với API. Trong ảnh chụp màn hình trước, chúng tôi đã nhận được phản hồi được hiển thị trong tab 21 được biểu thị ở định dạng 22. Điều này hoạt động vì API Bored là công khai và không yêu cầu bất kỳ khóa hoặc mã thông báo truy cập nào ( 23). Để kiểm tra các API được bảo vệ, thông thường trước tiên bạn cần có mã thông báo truy cập. Điều này có nghĩa là bạn phải có được thông tin đăng nhập cần thiết để có thể cấp mã thông báo truy cậpTruy cập API với Luồng thông tin xác thực của khách hàng 24 là một trong các loại cấp trong OAuth 2. 0 trong đó ứng dụng khách sử dụng 25, 26 và đôi khi là 27 để đổi lấy 28 để truy cập tài nguyên API được bảo vệLuồng này là cách được khuyến nghị để bảo mật API một cách dễ dàng mà không cần kết nối người dùng cụ thể, chủ yếu là cách tiếp cận này tốt hơn trong các tình huống từ máy chủ đến máy chủ, khi các ứng dụng nội bộ được kết nối với nhau trong một hệ thống cần xác thực mà không cần Giao diện người dùng đăng nhập để hiển thị thông tin đăng nhập biểu mẫu bằng tên người dùng và mật khẩu Trong Postman, bạn thường cần thực hiện một yêu cầu POST cùng với các tham số 29 sau
Sau đây là phản hồi mẫu sau khi yêu cầu mã thông báo truy cập từ Máy chủ ủy quyền trong Postman Trong ảnh chụp màn hình trước, tôi đang sử dụng IdentityServer4 hoạt động như Máy chủ mã thông báo để tạo mã thông báo và chạy cục bộ trên máy của tôi. Trong ví dụ này, Url của Tổ chức phát hành hoặc Cơ quan là 34. Hãy nhớ rằng Url có thể khác nhau tùy thuộc vào nhà cung cấp Danh tính của bạn. Điều này sẽ được cung cấp cho bạn cùng với 25, 26 và 27. Giá trị của 32 phải luôn là "client_credentials" đối với luồng Thông tin xác thực của khách hàngĐể biết thêm thông tin về IdentityServer4, hãy xem bài viết trước của tôi về Xây dựng Máy chủ Mã thông báo Đơn giản và Bảo vệ ASP của Bạn. NET Core API với JWT Thuộc tính 28 từ phản hồi JSON trong ảnh chụp màn hình trước đó là điều chúng tôi quan tâm. Đây là giá trị 23 mà chúng tôi cần thêm vào tiêu đề yêu cầu mỗi khi chúng tôi truy cập tài nguyên API được bảo vệ. Ví dụ: giả sử rằng chúng tôi muốn truy cập điểm cuối API 3 sau đây được bảo vệ bởi nhà cung cấp Danh tính của bạn 32Chỉ thực hiện một yêu cầu GET đơn giản trong Postman mà không có 33 sẽ dẫn đến 34 HttpStatus như sauĐể giải quyết vấn đề đó, chúng tôi có thể định cấu hình khóa 35 làm tiêu đề và đặt giá trị thành 36. Ảnh chụp màn hình sau đây là ví dụ về cách định cấu hình trong PostmanNhư bạn có thể thấy, sau khi định cấu hình mã thông báo mang làm tiêu đề Ủy quyền, dữ liệu hiện được trả về cho yêu cầu 37 với trạng thái 38Dễ dàng phải không? . Hãy tưởng tượng bạn có nhiều điểm cuối API khác nhau với các hành động khác nhau để kiểm tra. Với thiết lập này, cuối cùng bạn có thể thiết lập 33 và đặt mã thông báo mang mỗi khi bạn kiểm tra từng điểm cuối API. Điều này có thể khiến bạn mất thời gian phát triển và có thể làm giảm năng suất của bạnNhiều cách khác nhau để định cấu hình tạo mã thông báo BearerCách tiếp cận trước đây hoàn toàn phù hợp nếu bạn chỉ thử nghiệm một vài điểm cuối API, nhưng khi xử lý nhiều điểm cuối, bạn nên cân nhắc tự động hóa chúng càng nhiều càng tốt để cải thiện năng suất của mình. Hãy xem làm thế nào chúng ta có thể làm điều này trong Postman Vui lòng biết rằng có nhiều cách để thiết lập tự động hóa của bạn và đây chỉ là một trong số đó Cách tiếp cận đầu tiên là sử dụng tính năng Biến toàn cục của Postman. Hãy tiếp tục và nhấp vào biểu tượng "con mắt" như hình dưới đây Ngoài ra, bạn có thể nhấp vào biểu tượng "Môi trường" từ bảng điều khiển bên trái Nhấp vào bất kỳ biểu tượng nào sẽ hiển thị hộp thoại sau Ảnh chụp màn hình trước cho phép chúng tôi đặt các biến chung hoặc theo môi trường cụ thể. Nếu bạn đang xử lý nhiều môi trường như (Dev, Test, Stage và Prod), thì bạn có thể cân nhắc sử dụng tính năng Môi trường để thiết lập các biến dành riêng cho môi trường. Trong ví dụ này, chúng ta sẽ chỉ sử dụng một biến toàn cục để lưu trữ mã thông báo mang vì mục đích đơn giản Mẹo. Để biết thêm thông tin về cách sử dụng biến và phạm vi của chúng, hãy xem. Hiểu các biến Postman Bây giờ, hãy nhấp vào "Chỉnh sửa" và từ đó, bạn sẽ có thể xác định bất kỳ biến nào bạn cần. Đối với ví dụ này, chúng tôi sẽ lưu trữ giá trị của giá trị 28 trong một biến có tên là 21 như sauSau khi lưu cấu hình, biến 21 sẽ có thể truy cập được ở mọi nơi trong không gian làm việc của bạn bất kể bạn đang sử dụng môi trường nào. Đây là cấu hình cập nhật của yêu cầu 37 sử dụng biến 21Như bạn có thể thấy từ ảnh chụp màn hình trước, chúng tôi đã sử dụng tab 35 thay vì xác định thủ công khóa 35 trong tiêu đề yêu cầu. Điều này chỉ để cho bạn thấy một cách tốt hơn để đặt tiêu đề Ủy quyền vì bạn không phải nhập từ "Bearer" theo cách thủ công trước 28 hoặc 23. Trong cách tiếp cận cụ thể này, chúng tôi đã đặt loại 29 và tham chiếu biến 21 để điền vào Hộp văn bản 21. Người đưa thư sử dụng cú pháp 22 để thay thế các tên biến được đặt trong dấu ngoặc nhọn kép. Trong trường hợp này, giá trị 23 sẽ được điền bằng giá trị mã thông báo thực tếNgọt. Giờ đây, với phương pháp này, bạn có thể dễ dàng sử dụng lại biến 21 khi thử nghiệm các điểm cuối khác nhau mà không cần phải đặt lại giá trị mã thông báo mang theo cách thủ công. Mặc dù cách này hoạt động tốt hơn so với cách tiếp cận trước đó, nhưng cách này vẫn yêu cầu quy trình thủ công để cập nhật biến 21 với giá trị 28 mỗi khi mã thông báo hết hạn. Nghĩa là bạn gọi lại một yêu cầu đến Máy chủ ủy quyền, lấy mã thông báo mới và dán vào biến 21 để cập nhật giá trị. Đó là rất nhiều bướcChúng ta có thể cải thiện nó không?Đúng. Nhưng trước tiên, hãy tạo một vài biến bộ sưu tập để lưu trữ thông tin đăng nhập ủy quyền mà chúng tôi cần. Mẹo ở đây là nhóm tất cả các yêu cầu API của bạn thành một bộ sưu tập. Để thực hiện việc này, hãy nhấp vào menu "Bộ sưu tập" và sau đó nhấp vào biểu tượng 8 như minh họa trong hình dưới đâyBạn có thể đặt tên cho bộ sưu tập theo bất cứ thứ gì bạn thích miễn là nó có ý nghĩa. 😉 Đối với ví dụ này, chúng tôi sẽ đặt tên nó là "API thời tiết". Trong tab "Ủy quyền" của bộ sưu tập, chọn loại 29 giống như trong phần sauNhấp vào mục 90 sẽ hiển thị cho bạn một màn hình mới. Để lại các giá trị mặc định như bây giờ. Chúng tôi sẽ liên hệ lại với họ sauTiếp theo, hãy định cấu hình một vài biến bộ sưu tập cục bộ. Tiếp tục và chuyển sang tab 91 và thêm các mục sauTrong ảnh chụp màn hình trước, chúng tôi đã đặt các giá trị 92, 25, 26 và 27 trong biến riêng của nó. Chỉ cần đảm bảo rằng bạn thay thế các giá trị này bằng các giá trị chính xác mà bạn có và sau đó nhấp vào "Lưu". Lưu ý rằng chúng tôi đang sử dụng các biến cục bộ ở đây vì chúng tôi chỉ muốn hạn chế quyền truy cập trong bộ sưu tập "API thời tiết"Mẹo. Tùy thuộc vào nhu cầu của bạn hoặc nếu bạn thích, bạn cũng có thể xác định chúng trong các biến Toàn cầu hoặc Môi trường Bây giờ, chúng ta đã định cấu hình các biến cục bộ để sử dụng bộ sưu tập, hãy định cấu hình OAuth 2. 0 để tạo mã thông báo. Quay lại tab 35 và cuộn xuống phần dưới cùng nơi bạn tìm thấy phần "Định cấu hình mã thông báo mới"Trong screeshot trước, chúng tôi đã đặt Tên mã thông báo, Loại cấp và các trường khác dựa trên các biến bộ sưu tập mà chúng tôi đã xác định trước đó. Khi tất cả các giá trị được đặt, hãy nhấp vào nút "Nhận mã thông báo truy cập mới" và bạn sẽ thấy cửa sổ sau khi yêu cầu thành công và sau đó hiển thị phản hồi với 28 như hình dưới đâyCuối cùng, nhấp vào nút "Sử dụng mã thông báo" để điền Mã thông báo truy cập cho bộ sưu tập và sau đó nhấp vào "Lưu" để phản ánh các thay đổi cấu hình đối với bộ sưu tập Tại thời điểm này, bất cứ khi nào bạn thêm một yêu cầu mới trong bộ sưu tập "API thời tiết", tất cả yêu cầu sẽ được điền tự động bằng mã thông báo mang. Hãy xem điều đó trong hành động Bây giờ, nhấp vào liên kết 98 để tạo yêu cầu mới hoặc chỉ cần nhấp chuột phải vào thư mục bộ sưu tập và chọn "Thêm yêu cầu". Đối với ví dụ này, chúng tôi sẽ tạo một yêu cầu 3 để lấy danh sách dự báo thời tiết giống như trong ví dụ trước của chúng tôiLưu ý rằng trong tab 35, loại được tự động đặt thành "Kế thừa xác thực từ cấp độ gốc". Trong trường hợp này, cha mẹ là thư mục bộ sưu tập "API thời tiết". Bạn cũng sẽ thấy một thông báo cho biếtYêu cầu này đang sử dụng OAuth 2. 0 từ bộ sưu tập API thời tiết Điều đó có nghĩa là chúng tôi không cần định cấu hình bất kỳ tiêu đề 35 nào cho yêu cầu và có thể chỉ cần nhấp vào nút "Gửi" trực tiếp. Ảnh chụp màn hình sau đây cho thấy kết quả mẫu với phương pháp nàyTuyệt vời. Xin lưu ý rằng phương pháp trước đó vẫn có nhược điểm vì bạn vẫn sẽ được yêu cầu nhấp lại vào nút "Nhận mã thông báo truy cập mới" từ 02 của bộ sưu tập bất cứ khi nào mã thông báo hết hạn. Mặc dù nó không yêu cầu bạn sao chép và dán mã thông báo mới cho mỗi yêu cầu API của bạn, nhưng nó vẫn khá khó chịu và có thể là một gánh nặng, đặc biệt nếu bạn đang thử nghiệm một kịch bản trường hợp thử nghiệm chạy dài trong PostmanCó cách nào để tự động hóa hoàn toàn việc này không?bạn đặt cược. Chìa khóa để tự động hóa hoàn toàn là viết một kịch bản. May mắn thay, Postman có một tính năng cho phép chúng tôi viết các tập lệnh bằng JavaScript để thực hiện các hành động tùy chỉnh trước khi yêu cầu được gửi. Đây được gọi là "Tập lệnh yêu cầu trước" Trước khi chúng tôi bắt đầu viết tập lệnh để tự động hóa, hãy thêm các biến bộ sưu tập mới sau đây Ảnh chụp màn hình trước hiển thị các biến mới được thêm sau đây
Chúng tôi sẽ để trống các giá trị biến vì chúng tôi sẽ điền chúng một cách linh hoạt từ tập lệnh mà chúng tôi sẽ tạo tiếp theo Tạo tập lệnh yêu cầu trướcBây giờ, hãy chuyển sang tab "Tập lệnh yêu cầu trước" trong bộ sưu tập và sao chép các tập lệnh sau 0Hãy xem những gì chúng tôi vừa làm bằng cách phá mã Điều đầu tiên chúng tôi làm ở đó là lấy giá trị của biến 03. Khi chạy tập lệnh lần đầu tiên, lệnh gọi đó sẽ trả về một giá trị trống vì chúng tôi chưa đặt bất kỳ giá trị nào cho biến đó. Hãy xem mã tiếp theo
Đoạn mã trước khởi tạo biến 08 với ngày hôm trước. Điều này nhằm đảm bảo rằng chúng tôi đưa ra yêu cầu nhận mã thông báo truy cập mới trong lần chạy đầu tiên. Tương tự với việc xử lý giá trị 09 2Đoạn mã trước khởi tạo giá trị 09 thành 5 giây khi 04 trốngBây giờ chúng ta đã khởi tạo cả 08 và 09 với các giá trị mặc định. Sau đó, chúng tôi có thể thực hiện kiểm tra xác thực để so sánh các giá trị của chúng như được hiển thị trong đoạn mã sau 3Đoạn mã trước chuyển đổi 08 ở định dạng mili giây để chúng tôi có thể so sánh nó với 09. Rõ ràng, trong lần chạy đầu tiên, điều này sẽ dẫn đến 16 vì 08 được biểu thị bằng mili giây sẽ luôn lớn hơn 5 giây. Một lần nữa, đây là mục đích để chúng tôi có thể gửi yêu cầu lấy một 28 mới khi tập lệnh chạy lần đầu tiênTrong câu lệnh 19, chúng tôi đã gọi hàm 00 như sau 3Hàm 00 chịu trách nhiệm gọi một yêu cầu Http tới Máy chủ ủy quyền. Về cơ bản nó có 2 đối số. 1 cho yêu cầu và 2 để xử lý phản hồi. Trước tiên chúng ta hãy xem xét yêu cầu 2Đoạn mã trước tạo một yêu cầu Http POST tới Máy chủ ủy quyền. Vì vậy, thay vì chúng tôi gọi cuộc gọi này theo cách thủ công trong Postman, tập lệnh này sẽ tự động hóa quá trình đó. Bạn nhận thấy rằng tất cả các tham số 02 được trích xuất từ các biến mà chúng tôi đã xác định trong bộ sưu tập "API thời tiết". Điều này làm cho tập lệnh của chúng tôi rất dễ quản lý bất cứ khi nào mỗi giá trị đó được thay đổiĐối số thứ hai cho 00 là để gửi phản hồi dựa trên lệnh gọi yêu cầu Http như được hiển thị trong đoạn mã sau 2Đoạn mã trước là phần quan trọng của tập lệnh vì đây là nơi điều kỳ diệu xảy ra. Những gì mã làm sẽ trích xuất các giá trị từ phản hồi 22 và đặt các giá trị tương ứng cho các biến sau
Đó là nó. Xin nhắc lại, đừng quên "Lưu" tập lệnh của bạn trước khi chuyển sang tab khác Cập nhật cấu hình ủy quyềnBước cuối cùng mà chúng ta cần làm là cập nhật cấu hình Ủy quyền của mình. Tiếp tục và chuyển sang tab 35 và thay thế giá trị "Mã thông báo truy cập" bằng biến 13 giống như trong ảnh chụp màn hình sauTại thời điểm này, giờ đây chúng tôi có thể xóa tất cả các cấu hình trong phần "Định cấu hình mã thông báo mới" vì chúng tôi không còn chúng cho phương pháp này. Cách tiếp cận này hiện tự động hóa mọi thứ, không cần nhấp chuột thủ công, không cần sao chép và mọi yêu cầu sẽ tự động xác thực Bây giờ, hãy nhấn nút "Lưu" và bắt đầu gửi yêu cầu tới các API của bạn. Sau khi kiểm tra các API của mình, bạn sẽ nhận thấy rằng các biến mới mà chúng tôi đã xác định sẽ tự động được điền giống như trong ảnh chụp màn hình sau |