Hoang  Ha

Hoang Ha

1633935983

Làm mới mã thông báo là gì và cách sử dụng chúng một cách an toàn

Tìm hiểu về mã thông báo làm mới và cách chúng giúp các nhà phát triển cân bằng giữa bảo mật và khả năng sử dụng trong các ứng dụng của họ.

Bài đăng này sẽ khám phá khái niệm về mã thông báo làm mới theo định nghĩa của OAuth 2.0 . Chúng tôi sẽ tìm hiểu cách chúng so sánh với các loại mã thông báo khác và cách chúng cho phép chúng tôi cân bằng tính bảo mật, khả năng sử dụng và quyền riêng tư.

Mã thông báo là gì?

Mã thông báo là các phần dữ liệu chỉ mang đủ thông tin để tạo điều kiện thuận lợi cho quá trình xác định danh tính của người dùng hoặc ủy quyền cho người dùng thực hiện một hành động. Nói chung, mã thông báo là hiện vật cho phép các hệ thống ứng dụng thực hiện quá trình ủy quyền và xác thực.

Các khung và giao thức nhận dạng chung sử dụng các chiến lược dựa trên mã thông báo để bảo mật quyền truy cập vào các ứng dụng và tài nguyên. Ví dụ: chúng tôi có thể sử dụng OAuth 2.0 để ủy quyền và OIDC để xác thực.

OAuth 2.0 là một trong những khuôn khổ ủy quyền phổ biến nhất hiện có. Nó được thiết kế để cho phép một ứng dụng truy cập vào các tài nguyên được lưu trữ bởi các máy chủ khác thay mặt cho người dùng. OAuth 2.0 sử dụng Mã thông báo truy cập và Mã làm mới .

OpenID Connect (OIDC) là một giao thức nhận dạng thực hiện xác thực người dùng, sự đồng ý của người dùng và phát hành mã thông báo. OIDC sử dụng Mã thông báo ID .

Hãy cùng khám phá ba loại mã thông báo mà chúng tôi sử dụng với OAuth 2.0 và OpenID Connect để thực hiện các quy trình xác thực và ủy quyền của hệ thống ứng dụng của chúng tôi. Trong quá trình này, chúng ta sẽ thấy vai trò quan trọng của mã làm mới trong việc giúp các nhà phát triển xây dựng các ứng dụng mang lại sự tiện lợi mà không ảnh hưởng đến bảo mật.

Các loại mã thông báo

Mã thông báo ID là gì?

Như tên có thể gợi ý, mã thông báo ID là một cấu phần mà các ứng dụng khách có thể sử dụng để sử dụng danh tính của người dùng. Ví dụ: mã thông báo ID có thể chứa thông tin về tên, email và ảnh hồ sơ của người dùng. Do đó, các ứng dụng khách có thể sử dụng mã thông báo ID để xây dựng hồ sơ người dùng nhằm cá nhân hóa trải nghiệm người dùng.

Máy chủ xác thực tuân theo giao thức OpenID Connect (OIDC) để thực hiện quy trình xác thực sẽ cấp cho máy khách mã thông báo ID bất cứ khi nào người dùng đăng nhập. Người tiêu dùng mã thông báo ID chủ yếu là các ứng dụng khách như Ứng dụng một trang (SPA) và thiết bị di động các ứng dụng. Họ là đối tượng dự định.

Mã thông báo truy cập là gì?

Khi người dùng đăng nhập, máy chủ ủy quyền sẽ cấp mã thông báo truy cập , này là một cấu phần mà các ứng dụng khách có thể sử dụng để thực hiện các cuộc gọi an toàn đến máy chủ API. Khi ứng dụng khách cần truy cập tài nguyên được bảo vệ trên máy chủ thay mặt cho người dùng, mã thông báo truy cập cho phép ứng dụng báo hiệu với máy chủ rằng nó đã được người dùng ủy quyền để thực hiện các tác vụ nhất định hoặc truy cập tài nguyên nhất định.

OAuth 2.0 không xác định định dạng cho mã thông báo truy cập. Ví dụ: tại Auth0, mã thông báo truy cập được cấp cho API quản lý và mã truy cập được cấp cho bất kỳ API tùy chỉnh nào mà bạn đã đăng ký với Auth0 tuân theo tiêu chuẩn Mã thông báo web JSON (JWT) . Cấu trúc cơ bản của chúng tuân theo cấu trúc JWT điển hình và chúng chứa các tuyên bố JWT tiêu chuẩn được khẳng định về chính mã thông báo.

Đây là nội dung của mã thông báo truy cập được giải mã tuân theo định dạng JWT:

{
  "iss": "https://YOUR_DOMAIN/",
  "sub": "auth0|123456",
  "aud": [
    "my-api-identifier",
    "https://YOUR_DOMAIN/userinfo"
  ],
  "azp": "YOUR_CLIENT_ID",
  "exp": 1489179954,
  "iat": 1489143954,
  "scope": "openid profile email address phone read:appointments"
}

Điều quan trọng cần làm nổi bật là mã thông báo truy cập là mã thông báo mang. Những người nắm giữ mã thông báo có thể sử dụng nó. Sau đó, mã thông báo truy cập hoạt động như một cấu phần xác thực để truy cập các tài nguyên được bảo vệ chứ không phải là một cấu phần nhận dạng. Người dùng độc hại về mặt lý thuyết có thể xâm phạm hệ thống và đánh cắp mã thông báo truy cập, do đó họ có thể sử dụng để truy cập các tài nguyên được bảo vệ bằng cách trình bày trực tiếp các mã thông báo đó lên máy chủ.

Do đó, điều quan trọng là phải có các chiến lược bảo mật để giảm thiểu nguy cơ ảnh hưởng đến mã thông báo truy cập. Một phương pháp giảm thiểu là tạo mã thông báo truy cập có tuổi thọ ngắn: chúng chỉ có giá trị trong một thời gian ngắn được xác định theo giờ hoặc ngày.

Có nhiều cách khác nhau mà ứng dụng khách có thể nhận được mã thông báo truy cập mới cho người dùng. Ví dụ: khi mã thông báo truy cập hết hạn, ứng dụng khách có thể nhắc người dùng đăng nhập lại để nhận mã thông báo truy cập mới. Ngoài ra, máy chủ ủy quyền có thể phát hành mã làm mới cho ứng dụng khách để cho phép nó thay thế mã thông báo truy cập đã hết hạn bằng một mã mới.

Mã làm mới là gì?

Như đã đề cập, vì mục đích bảo mật, mã thông báo truy cập có thể có giá trị trong một khoảng thời gian ngắn. Khi chúng hết hạn, các ứng dụng khách có thể sử dụng mã làm mới để "làm mới" mã thông báo truy cập. Nghĩa là, mã thông báo làm mới là một tạo tác thông tin xác thực cho phép ứng dụng khách nhận mã thông báo truy cập mới mà không cần phải yêu cầu người dùng đăng nhập lại.

Hệ thống ứng dụng trong đó SPA sử dụng mã thông báo làm mới để lấy mã thông báo truy cập mới

Trong sơ đồ trên, SPA = Ứng dụng một trang; AS = Máy chủ ủy quyền; RS = Máy chủ tài nguyên; AT = Mã thông báo truy cập; RT = Làm mới Mã thông báo.

Ứng dụng khách có thể nhận được mã thông báo truy cập mới miễn là mã thông báo làm mới hợp lệ và chưa hết hạn. Do đó, một mã thông báo làm mới có tuổi thọ rất dài về mặt lý thuyết có thể cung cấp sức mạnh vô hạn cho người mang mã thông báo để có được mã thông báo truy cập mới để truy cập các tài nguyên được bảo vệ bất cứ lúc nào. Người mang mã thông báo làm mới có thể là người dùng hợp pháp hoặc người dùng độc hại. Do đó, các công ty bảo mật, chẳng hạn như Auth0, tạo ra các cơ chế để đảm bảo rằng mã thông báo mạnh mẽ này chủ yếu được các bên dự định nắm giữ và sử dụng liên tục.

Khi nào sử dụng mã làm mới

Điều quan trọng cần lưu ý là đặc tả OAuth 2.0 xác định mã thông báo truy cập và mã làm mới. Vì vậy, nếu chúng ta thảo luận về các chiến lược ủy quyền về các giao thức hoặc khuôn khổ nhận dạng khác, chẳng hạn như SAML, chúng ta sẽ không có khái niệm về mã thông báo truy cập hoặc mã thông báo làm mới.

Đối với những người liên quan đến phát triển web, mã thông báo truy cập và mã thông báo làm mới là cuộc nói chuyện phổ biến vì web sử dụng rộng rãi xác thực và ủy quyền dựa trên mã thông báo thông qua khung OAuth 2.0 và giao thức OpenID Connect.

Khi được kết hợp, OAuth 2.0 và OIDC mang lại sự sống động cho một loạt các luồng xác thực và ủy quyền. Mỗi luồng có một bộ lợi ích và lưu ý riêng xác định các kịch bản và kiến ​​trúc tốt nhất mà chúng ta nên sử dụng mã thông báo truy cập và làm mới.

Máy khách có phải là ứng dụng web truyền thống đang thực thi trên máy chủ không? Sử dụng Quy trình mã ủy quyền .

Khách hàng có phải là Ứng dụng một trang (SPA) không? Sử dụng Luồng mã ủy quyền với Khóa bằng chứng cho Trao đổi mã (PKCE) .

Ứng dụng khách có phải là Ứng dụng một trang (SPA) không cần mã thông báo truy cập không? Sử dụng Quy trình ngầm định với Bài đăng trên Biểu mẫu .

Khách hàng có phải là chủ sở hữu tài nguyên không? Bạn có thể sử dụng Quy trình thông tin xác thực khách hàng .

Khách hàng có tin cậy tuyệt đối với thông tin đăng nhập của người dùng không? Bạn có thể sử dụng Luồng mật khẩu của chủ sở hữu tài nguyên .

Nếu có một ứng dụng cho điều đó, thì cũng có một luồng cho điều đó!

Hãy nhớ rằng theo thông số kỹ thuật, khi sử dụng Dòng chảy ngầm định, máy chủ ủy quyền sẽ không phát hành mã thông báo làm mới. Luồng ngầm thường được triển khai trong Ứng dụng một trang (SPA), chạy trên lớp giao diện người dùng của kiến ​​trúc hệ thống. Không có cách nào dễ dàng để giữ mã thông báo làm mới an toàn trong lớp giao diện người dùng của riêng nó.

Việc sử dụng Luồng mã ủy quyền với Khóa bằng chứng để trao đổi mã (PKCE) sẽ giảm thiểu nhiều rủi ro vốn có đối với Luồng ngầm. Ví dụ: khi sử dụng kiểu cấp ngầm, mã thông báo truy cập được truyền trong phân đoạn URI , có thể khiến cho các bên không được phép tiếp xúc. Bạn có thể tìm hiểu thêm về các lỗ hổng này bằng cách đọc phần "Lạm dụng mã truy cập để mạo danh chủ sở hữu tài nguyên trong dòng ngầm" của thông số kỹ thuật.

Tuy nhiên, việc triển khai PKCE trong các ứng dụng của bạn vẫn không ảnh hưởng đến mức độ an toàn của các mã làm mới.

Tuy nhiên, bạn có thể không cần mã thông báo làm mới.

Có những tình huống mà bạn vẫn có thể nhận được mã thông báo truy cập mà không làm gián đoạn người dùng và không cần dựa vào sức mạnh toàn năng của mã thông báo làm mới. Các ví dụ khác để duy trì một phiên có thể là cookie hoặc xác thực im lặng .

Tuy nhiên, hàng tỷ người sử dụng SPA mỗi ngày. Điều quan trọng là phải cung cấp cho người dùng trải nghiệm người dùng cân bằng tốt giữa bảo mật và tiện lợi . Có điều gì chúng tôi có thể làm để cho phép các SPA tạo điều kiện thuận lợi cho việc làm mới mã thông báo theo cách ít rủi ro hơn và an toàn hơn không?

Chắc chắn rồi!

Một nền tảng nhận dạng cung cấp Xoay vòng làm mới mã thông báo làm cho việc sử dụng mã thông báo làm mới với Ứng dụng một trang được chấp nhận. Thông số nhấn mạnh rằng khi bạn không thể xác minh rằng mã thông báo làm mới thuộc về một ứng dụng khách, một SPA như vậy, chúng tôi không nên sử dụng chúng trừ khi chúng tôi có Xoay mã làm mới tại chỗ .

Hãy cùng tìm hiểu thêm về chiến lược bảo mật này trong phần tiếp theo.

Giữ an toàn cho mã thông báo làm mới

Mã thông báo truy cập tồn tại trong thời gian ngắn giúp cải thiện tính bảo mật của các ứng dụng của chúng tôi, nhưng nó đi kèm với một cái giá phải trả: khi nó hết hạn, người dùng cần đăng nhập lại để nhận mã mới. Việc xác thực lại thường xuyên có thể làm giảm trải nghiệm người dùng nhận thức được về ứng dụng của bạn. Ngay cả khi bạn làm như vậy để bảo vệ dữ liệu của họ, người dùng có thể thấy dịch vụ của bạn gây khó chịu hoặc khó sử dụng.

Mã thông báo làm mới có thể giúp bạn cân bằng giữa bảo mật với khả năng sử dụng. Vì mã thông báo làm mới thường tồn tại lâu hơn, bạn có thể sử dụng chúng để yêu cầu mã thông báo truy cập mới sau khi mã thông báo truy cập có tuổi thọ ngắn hơn hết hạn.

Tuy nhiên, vì mã thông báo làm mới cũng là mã thông báo mang, chúng tôi cần phải có một chiến lược để hạn chế hoặc cắt giảm việc sử dụng chúng nếu chúng bị rò rỉ hoặc bị xâm phạm. Tất cả những người nắm giữ mã thông báo làm mới đều có quyền nhận mã thông báo truy cập mới bất cứ khi nào họ muốn. "Họ" có thể là người dùng hợp pháp hoặc kẻ tấn công.

Tại Auth0, chúng tôi đã tạo ra một tập hợp các tính năng giúp giảm thiểu rủi ro liên quan đến việc sử dụng mã thông báo làm mới bằng cách áp đặt các biện pháp bảo vệ và kiểm soát đối với vòng đời của chúng. Nền tảng nhận dạng của chúng tôi cung cấp xoay vòng mã thông báo làm mới, cũng đi kèm với tính năng phát hiện sử dụng lại tự động.

Hãy đi sâu hơn vào kỹ thuật bảo mật này.

Làm mới xoay vòng mã thông báo

Cho đến gần đây, một chiến lược mạnh mẽ để giúp các SPA duy trì phiên của người dùng là sử dụng Luồng mã ủy quyền với PKCE kết hợp với xác thực im lặng. Làm mới vòng quay mã thông báo là một kỹ thuật để nhận mã thông báo truy cập mới bằng cách sử dụng mã làm mới vượt ra ngoài xác thực im lặng .

Vòng quay mã thông báo làm mới đảm bảo rằng mỗi khi ứng dụng trao đổi mã thông báo làm mới để lấy mã thông báo truy cập mới, thì mã làm mới mới cũng được trả lại. Do đó, bạn không còn mã thông báo làm mới tồn tại lâu dài có thể cung cấp quyền truy cập bất hợp pháp vào tài nguyên nếu nó bị xâm phạm. Mối đe dọa về việc truy cập bất hợp pháp được giảm bớt khi các mã thông báo làm mới liên tục được trao đổi và mất hiệu lực.

Ví dụ: với tính năng xoay vòng mã thông báo làm mới được bật trong Bảng điều khiển Auth0, mỗi khi ứng dụng của bạn trao đổi mã thông báo làm mới để lấy mã thông báo truy cập mới, máy chủ ủy quyền cũng trả về một cặp mã thông báo truy cập làm mới mới. Biện pháp bảo vệ này giúp ứng dụng của bạn giảm thiểu các cuộc tấn công phát lại do các mã thông báo bị xâm phạm.

Làm mới mã thông báo tự động phát hiện sử dụng lại

Mã thông báo làm mới là mã thông báo không mang. Máy chủ ủy quyền không thể biết ai là hợp pháp hoặc độc hại khi nhận được yêu cầu mã thông báo truy cập mới. Sau đó, chúng tôi có thể coi tất cả người dùng là có khả năng độc hại.

Làm thế nào chúng ta có thể xử lý tình huống có điều kiện chạy đua giữa người dùng hợp pháp và người dùng độc hại? Ví dụ:

🐱 Người dùng hợp pháp🔄 Mã làm mới 1🔑 Mã truy cập 1 .

😈 Người dùng độc hại quản lý để đánh cắp 🔄 Làm mới mã thông báo 1 từ 🐱 Người dùng hợp pháp .

🐱 Người dùng hợp pháp sử dụng 🔄 Làm mới Mã thông báo 1 để nhận một cặp mã thông báo truy cập làm mới mới.

Các 🚓 Auth0 Authorization server nhuận 🔄 Refresh Mã 2🔑 access token 2 đến 🐱 hợp pháp tài .

😈 Người dùng độc hại sau đó cố gắng sử dụng 🔄 Làm mới mã thông báo 1 để nhận mã thông báo truy cập mới. Thuần ác!

Bạn nghĩ điều gì sẽ xảy ra tiếp theo? Would 😈 độc hại tài quản lý để nhận mã truy cập mới?

Đây là những gì sẽ xảy ra khi nền tảng danh tính của bạn có 🤖 Phát hiện tái sử dụng tự động :

Các 🚓 Auth0 Authorization máy chủ đã được lưu giữ theo dõi của tất cả các mã thông báo refresh giảm dần từ refresh dấu hiệu ban đầu. Đó là, nó đã tạo ra một "gia đình mã thông báo".

Các 🚓 Auth0 Authorization máy chủ nhận ra rằng ai đó đang tái sử dụng 🔄 Refresh Mã 1 và ngay lập tức làm mất hiệu lực gia đình thẻ làm mới, bao gồm 🔄 Refresh Mã 2 .

Các 🚓 Auth0 Authorization server trả về một Access Denied đối phó với 😈 độc hại tài .

🔑 Mã thông báo truy cập 2 hết hạn và 🐱 Người dùng hợp pháp cố gắng sử dụng 🔄 Mã thông báo làm mới 2 để yêu cầu một cặp mã thông báo truy cập làm mới mới.

Các 🚓 Auth0 Authorization server trả về một Access Denied đối phó với 🐱 hợp pháp tài .

Các 🚓 Auth0 Authorization máy chủ đòi hỏi phải tái thẩm định để có được truy cập mới và thẻ làm mới.

Điều quan trọng là mã làm mới được phát hành gần đây nhất phải bị vô hiệu ngay lập tức khi mã làm mới đã sử dụng trước đó được gửi đến máy chủ ủy quyền. Điều này ngăn không cho bất kỳ mã làm mới nào trong cùng một họ mã thông báo được sử dụng để nhận mã thông báo truy cập mới.

Cơ chế bảo vệ này hoạt động bất kể người dùng hợp pháp hay độc hại có thể trao đổi 🔄 Mã thông báo làm mới 1 để lấy cặp mã thông báo truy cập làm mới mới trước cặp mã kia. Nếu không thực thi ràng buộc người gửi, máy chủ ủy quyền không thể biết tác nhân nào là hợp pháp hoặc độc hại trong trường hợp tấn công phát lại.

Tự động phát hiện sử dụng lại là một thành phần chính của chiến lược xoay vòng mã thông báo làm mới. Máy chủ đã làm mất hiệu lực mã thông báo làm mới đã được sử dụng. Tuy nhiên, vì máy chủ ủy quyền không có cách nào để biết liệu người dùng hợp pháp có đang nắm giữ mã thông báo làm mới mới nhất hay không, nên nó sẽ làm mất hiệu lực toàn bộ họ mã thông báo chỉ để an toàn.

Làm mới mã thông báo giúp chúng tôi nắm bắt các công cụ bảo mật

Quyền riêng tư là một chủ đề nóng trong thế giới kỹ thuật số của chúng tôi. Chúng ta không chỉ cần cân bằng giữa bảo mật với tiện lợi mà còn cần thêm quyền riêng tư vào hành động cân bằng.

Những phát triển gần đây trong công nghệ bảo mật của trình duyệt, chẳng hạn như Ngăn chặn Theo dõi Thông minh (ITP), ngăn chặn quyền truy cập vào cookie phiên, yêu cầu người dùng xác thực lại.

Không có cơ chế lưu trữ liên tục nào trong một trình duyệt chỉ có thể đảm bảo quyền truy cập của ứng dụng đã định. Do đó, các mã thông báo làm mới tồn tại lâu dài không phù hợp với các SPA vì có những lỗ hổng mà người dùng độc hại có thể khai thác để lấy được các tạo tác có giá trị cao này, cấp cho họ quyền truy cập vào các tài nguyên được bảo vệ.

Vì xoay vòng mã thông báo làm mới không dựa vào quyền truy cập vào cookie phiên Auth0, nó không bị ảnh hưởng bởi ITP hoặc các cơ chế tương tự.

Tuy nhiên, mã thông báo làm mới có thể có tuổi thọ của nó bị giới hạn bởi tuổi thọ của mã thông báo truy cập. Điều này có nghĩa là chúng tôi có thể sử dụng mã làm mới một cách an toàn để chơi cùng với các công cụ bảo mật của trình duyệt và cung cấp quyền truy cập liên tục cho người dùng cuối mà không làm gián đoạn trải nghiệm người dùng.

Bạn có thể lưu trữ mã làm mới trong bộ nhớ cục bộ

Bạn đã đọc đúng. Khi chúng tôi có vòng quay mã thông báo làm mới tại chỗ, chúng tôi có thể lưu trữ mã thông báo trong bộ nhớ cục bộ hoặc bộ nhớ trình duyệt.

Bạn có thể đã nghe trước đây (có thể từ chúng tôi) rằng chúng tôi không nên lưu trữ mã thông báo trong bộ nhớ cục bộ.

Lưu trữ mã thông báo trong bộ nhớ cục bộ của trình duyệt cung cấp sự bền bỉ trên các lần làm mới trang và các tab trình duyệt; tuy nhiên, nếu người dùng độc hại quản lý để chạy JavaScript trong SPA bằng cách sử dụng cuộc tấn công tập lệnh trên nhiều trang web (XSS), họ có thể truy xuất mã thông báo được lưu trữ trong bộ nhớ cục bộ. Một lỗ hổng dẫn đến một cuộc tấn công XSS thành công có thể có trong mã nguồn SPA hoặc bất kỳ mã JavaScript nào của bên thứ ba mà ứng dụng sử dụng, chẳng hạn như Bootstrap hoặc Google Analytics.

Tuy nhiên, chúng tôi có thể giảm thời gian hết hạn tuyệt đối của mã thông báo để giảm rủi ro bảo mật khi lưu trữ mã thông báo trong bộ nhớ cục bộ. Điều này làm giảm tác động của một cuộc tấn công XSS được phản ánh (nhưng không phải là một cuộc tấn công dai dẳng). Mã thông báo làm mới có thể có tuổi thọ lâu dài theo cấu hình. Tuy nhiên, tuổi thọ dài được xác định của mã thông báo làm mới bị cắt ngắn với việc xoay vòng mã thông báo làm mới. Việc làm mới chỉ hợp lệ trong vòng đời của mã thông báo truy cập, sẽ tồn tại trong thời gian ngắn.

Sử dụng mã làm mới trong ứng dụng Auth0 của bạn

Nếu bạn quan tâm đến việc thêm xác thực và ủy quyền vào ứng dụng của mình chỉ trong vài bước, hãy đăng ký tài khoản Auth0 miễn phí ngay bây giờ .

Tài liệu "Các phương pháp hay nhất về mã thông báo " của chúng tôi nêu một số lưu ý cơ bản cần ghi nhớ khi sử dụng mã thông báo:

  • Giữ bí mật. Giữ nó an toàn.
  • Không thêm dữ liệu nhạy cảm vào tải trọng.
  • Cung cấp cho các mã thông báo hết hạn.
  • Nắm bắt HTTPS.
  • Xem xét tất cả các trường hợp sử dụng ủy quyền của bạn.
  • Lưu trữ và tái sử dụng.

Bảng điều khiển Auth0 giúp bạn dễ dàng định cấu hình các dịch vụ xác thực và ủy quyền để sử dụng mã thông báo làm mới. Các thư viện và SDK Auth0 hỗ trợ mã thông báo làm mới cho các ứng dụng web, Ứng dụng một trang (SPA) và ứng dụng gốc / ứng dụng dành cho thiết bị di động.

Nguồn: https://auth0.com

#jwt #auth0 #security #jwt 

What is GEEK

Buddha Community

Làm mới mã thông báo là gì và cách sử dụng chúng một cách an toàn
Hoang  Ha

Hoang Ha

1633935983

Làm mới mã thông báo là gì và cách sử dụng chúng một cách an toàn

Tìm hiểu về mã thông báo làm mới và cách chúng giúp các nhà phát triển cân bằng giữa bảo mật và khả năng sử dụng trong các ứng dụng của họ.

Bài đăng này sẽ khám phá khái niệm về mã thông báo làm mới theo định nghĩa của OAuth 2.0 . Chúng tôi sẽ tìm hiểu cách chúng so sánh với các loại mã thông báo khác và cách chúng cho phép chúng tôi cân bằng tính bảo mật, khả năng sử dụng và quyền riêng tư.

Mã thông báo là gì?

Mã thông báo là các phần dữ liệu chỉ mang đủ thông tin để tạo điều kiện thuận lợi cho quá trình xác định danh tính của người dùng hoặc ủy quyền cho người dùng thực hiện một hành động. Nói chung, mã thông báo là hiện vật cho phép các hệ thống ứng dụng thực hiện quá trình ủy quyền và xác thực.

Các khung và giao thức nhận dạng chung sử dụng các chiến lược dựa trên mã thông báo để bảo mật quyền truy cập vào các ứng dụng và tài nguyên. Ví dụ: chúng tôi có thể sử dụng OAuth 2.0 để ủy quyền và OIDC để xác thực.

OAuth 2.0 là một trong những khuôn khổ ủy quyền phổ biến nhất hiện có. Nó được thiết kế để cho phép một ứng dụng truy cập vào các tài nguyên được lưu trữ bởi các máy chủ khác thay mặt cho người dùng. OAuth 2.0 sử dụng Mã thông báo truy cập và Mã làm mới .

OpenID Connect (OIDC) là một giao thức nhận dạng thực hiện xác thực người dùng, sự đồng ý của người dùng và phát hành mã thông báo. OIDC sử dụng Mã thông báo ID .

Hãy cùng khám phá ba loại mã thông báo mà chúng tôi sử dụng với OAuth 2.0 và OpenID Connect để thực hiện các quy trình xác thực và ủy quyền của hệ thống ứng dụng của chúng tôi. Trong quá trình này, chúng ta sẽ thấy vai trò quan trọng của mã làm mới trong việc giúp các nhà phát triển xây dựng các ứng dụng mang lại sự tiện lợi mà không ảnh hưởng đến bảo mật.

Các loại mã thông báo

Mã thông báo ID là gì?

Như tên có thể gợi ý, mã thông báo ID là một cấu phần mà các ứng dụng khách có thể sử dụng để sử dụng danh tính của người dùng. Ví dụ: mã thông báo ID có thể chứa thông tin về tên, email và ảnh hồ sơ của người dùng. Do đó, các ứng dụng khách có thể sử dụng mã thông báo ID để xây dựng hồ sơ người dùng nhằm cá nhân hóa trải nghiệm người dùng.

Máy chủ xác thực tuân theo giao thức OpenID Connect (OIDC) để thực hiện quy trình xác thực sẽ cấp cho máy khách mã thông báo ID bất cứ khi nào người dùng đăng nhập. Người tiêu dùng mã thông báo ID chủ yếu là các ứng dụng khách như Ứng dụng một trang (SPA) và thiết bị di động các ứng dụng. Họ là đối tượng dự định.

Mã thông báo truy cập là gì?

Khi người dùng đăng nhập, máy chủ ủy quyền sẽ cấp mã thông báo truy cập , này là một cấu phần mà các ứng dụng khách có thể sử dụng để thực hiện các cuộc gọi an toàn đến máy chủ API. Khi ứng dụng khách cần truy cập tài nguyên được bảo vệ trên máy chủ thay mặt cho người dùng, mã thông báo truy cập cho phép ứng dụng báo hiệu với máy chủ rằng nó đã được người dùng ủy quyền để thực hiện các tác vụ nhất định hoặc truy cập tài nguyên nhất định.

OAuth 2.0 không xác định định dạng cho mã thông báo truy cập. Ví dụ: tại Auth0, mã thông báo truy cập được cấp cho API quản lý và mã truy cập được cấp cho bất kỳ API tùy chỉnh nào mà bạn đã đăng ký với Auth0 tuân theo tiêu chuẩn Mã thông báo web JSON (JWT) . Cấu trúc cơ bản của chúng tuân theo cấu trúc JWT điển hình và chúng chứa các tuyên bố JWT tiêu chuẩn được khẳng định về chính mã thông báo.

Đây là nội dung của mã thông báo truy cập được giải mã tuân theo định dạng JWT:

{
  "iss": "https://YOUR_DOMAIN/",
  "sub": "auth0|123456",
  "aud": [
    "my-api-identifier",
    "https://YOUR_DOMAIN/userinfo"
  ],
  "azp": "YOUR_CLIENT_ID",
  "exp": 1489179954,
  "iat": 1489143954,
  "scope": "openid profile email address phone read:appointments"
}

Điều quan trọng cần làm nổi bật là mã thông báo truy cập là mã thông báo mang. Những người nắm giữ mã thông báo có thể sử dụng nó. Sau đó, mã thông báo truy cập hoạt động như một cấu phần xác thực để truy cập các tài nguyên được bảo vệ chứ không phải là một cấu phần nhận dạng. Người dùng độc hại về mặt lý thuyết có thể xâm phạm hệ thống và đánh cắp mã thông báo truy cập, do đó họ có thể sử dụng để truy cập các tài nguyên được bảo vệ bằng cách trình bày trực tiếp các mã thông báo đó lên máy chủ.

Do đó, điều quan trọng là phải có các chiến lược bảo mật để giảm thiểu nguy cơ ảnh hưởng đến mã thông báo truy cập. Một phương pháp giảm thiểu là tạo mã thông báo truy cập có tuổi thọ ngắn: chúng chỉ có giá trị trong một thời gian ngắn được xác định theo giờ hoặc ngày.

Có nhiều cách khác nhau mà ứng dụng khách có thể nhận được mã thông báo truy cập mới cho người dùng. Ví dụ: khi mã thông báo truy cập hết hạn, ứng dụng khách có thể nhắc người dùng đăng nhập lại để nhận mã thông báo truy cập mới. Ngoài ra, máy chủ ủy quyền có thể phát hành mã làm mới cho ứng dụng khách để cho phép nó thay thế mã thông báo truy cập đã hết hạn bằng một mã mới.

Mã làm mới là gì?

Như đã đề cập, vì mục đích bảo mật, mã thông báo truy cập có thể có giá trị trong một khoảng thời gian ngắn. Khi chúng hết hạn, các ứng dụng khách có thể sử dụng mã làm mới để "làm mới" mã thông báo truy cập. Nghĩa là, mã thông báo làm mới là một tạo tác thông tin xác thực cho phép ứng dụng khách nhận mã thông báo truy cập mới mà không cần phải yêu cầu người dùng đăng nhập lại.

Hệ thống ứng dụng trong đó SPA sử dụng mã thông báo làm mới để lấy mã thông báo truy cập mới

Trong sơ đồ trên, SPA = Ứng dụng một trang; AS = Máy chủ ủy quyền; RS = Máy chủ tài nguyên; AT = Mã thông báo truy cập; RT = Làm mới Mã thông báo.

Ứng dụng khách có thể nhận được mã thông báo truy cập mới miễn là mã thông báo làm mới hợp lệ và chưa hết hạn. Do đó, một mã thông báo làm mới có tuổi thọ rất dài về mặt lý thuyết có thể cung cấp sức mạnh vô hạn cho người mang mã thông báo để có được mã thông báo truy cập mới để truy cập các tài nguyên được bảo vệ bất cứ lúc nào. Người mang mã thông báo làm mới có thể là người dùng hợp pháp hoặc người dùng độc hại. Do đó, các công ty bảo mật, chẳng hạn như Auth0, tạo ra các cơ chế để đảm bảo rằng mã thông báo mạnh mẽ này chủ yếu được các bên dự định nắm giữ và sử dụng liên tục.

Khi nào sử dụng mã làm mới

Điều quan trọng cần lưu ý là đặc tả OAuth 2.0 xác định mã thông báo truy cập và mã làm mới. Vì vậy, nếu chúng ta thảo luận về các chiến lược ủy quyền về các giao thức hoặc khuôn khổ nhận dạng khác, chẳng hạn như SAML, chúng ta sẽ không có khái niệm về mã thông báo truy cập hoặc mã thông báo làm mới.

Đối với những người liên quan đến phát triển web, mã thông báo truy cập và mã thông báo làm mới là cuộc nói chuyện phổ biến vì web sử dụng rộng rãi xác thực và ủy quyền dựa trên mã thông báo thông qua khung OAuth 2.0 và giao thức OpenID Connect.

Khi được kết hợp, OAuth 2.0 và OIDC mang lại sự sống động cho một loạt các luồng xác thực và ủy quyền. Mỗi luồng có một bộ lợi ích và lưu ý riêng xác định các kịch bản và kiến ​​trúc tốt nhất mà chúng ta nên sử dụng mã thông báo truy cập và làm mới.

Máy khách có phải là ứng dụng web truyền thống đang thực thi trên máy chủ không? Sử dụng Quy trình mã ủy quyền .

Khách hàng có phải là Ứng dụng một trang (SPA) không? Sử dụng Luồng mã ủy quyền với Khóa bằng chứng cho Trao đổi mã (PKCE) .

Ứng dụng khách có phải là Ứng dụng một trang (SPA) không cần mã thông báo truy cập không? Sử dụng Quy trình ngầm định với Bài đăng trên Biểu mẫu .

Khách hàng có phải là chủ sở hữu tài nguyên không? Bạn có thể sử dụng Quy trình thông tin xác thực khách hàng .

Khách hàng có tin cậy tuyệt đối với thông tin đăng nhập của người dùng không? Bạn có thể sử dụng Luồng mật khẩu của chủ sở hữu tài nguyên .

Nếu có một ứng dụng cho điều đó, thì cũng có một luồng cho điều đó!

Hãy nhớ rằng theo thông số kỹ thuật, khi sử dụng Dòng chảy ngầm định, máy chủ ủy quyền sẽ không phát hành mã thông báo làm mới. Luồng ngầm thường được triển khai trong Ứng dụng một trang (SPA), chạy trên lớp giao diện người dùng của kiến ​​trúc hệ thống. Không có cách nào dễ dàng để giữ mã thông báo làm mới an toàn trong lớp giao diện người dùng của riêng nó.

Việc sử dụng Luồng mã ủy quyền với Khóa bằng chứng để trao đổi mã (PKCE) sẽ giảm thiểu nhiều rủi ro vốn có đối với Luồng ngầm. Ví dụ: khi sử dụng kiểu cấp ngầm, mã thông báo truy cập được truyền trong phân đoạn URI , có thể khiến cho các bên không được phép tiếp xúc. Bạn có thể tìm hiểu thêm về các lỗ hổng này bằng cách đọc phần "Lạm dụng mã truy cập để mạo danh chủ sở hữu tài nguyên trong dòng ngầm" của thông số kỹ thuật.

Tuy nhiên, việc triển khai PKCE trong các ứng dụng của bạn vẫn không ảnh hưởng đến mức độ an toàn của các mã làm mới.

Tuy nhiên, bạn có thể không cần mã thông báo làm mới.

Có những tình huống mà bạn vẫn có thể nhận được mã thông báo truy cập mà không làm gián đoạn người dùng và không cần dựa vào sức mạnh toàn năng của mã thông báo làm mới. Các ví dụ khác để duy trì một phiên có thể là cookie hoặc xác thực im lặng .

Tuy nhiên, hàng tỷ người sử dụng SPA mỗi ngày. Điều quan trọng là phải cung cấp cho người dùng trải nghiệm người dùng cân bằng tốt giữa bảo mật và tiện lợi . Có điều gì chúng tôi có thể làm để cho phép các SPA tạo điều kiện thuận lợi cho việc làm mới mã thông báo theo cách ít rủi ro hơn và an toàn hơn không?

Chắc chắn rồi!

Một nền tảng nhận dạng cung cấp Xoay vòng làm mới mã thông báo làm cho việc sử dụng mã thông báo làm mới với Ứng dụng một trang được chấp nhận. Thông số nhấn mạnh rằng khi bạn không thể xác minh rằng mã thông báo làm mới thuộc về một ứng dụng khách, một SPA như vậy, chúng tôi không nên sử dụng chúng trừ khi chúng tôi có Xoay mã làm mới tại chỗ .

Hãy cùng tìm hiểu thêm về chiến lược bảo mật này trong phần tiếp theo.

Giữ an toàn cho mã thông báo làm mới

Mã thông báo truy cập tồn tại trong thời gian ngắn giúp cải thiện tính bảo mật của các ứng dụng của chúng tôi, nhưng nó đi kèm với một cái giá phải trả: khi nó hết hạn, người dùng cần đăng nhập lại để nhận mã mới. Việc xác thực lại thường xuyên có thể làm giảm trải nghiệm người dùng nhận thức được về ứng dụng của bạn. Ngay cả khi bạn làm như vậy để bảo vệ dữ liệu của họ, người dùng có thể thấy dịch vụ của bạn gây khó chịu hoặc khó sử dụng.

Mã thông báo làm mới có thể giúp bạn cân bằng giữa bảo mật với khả năng sử dụng. Vì mã thông báo làm mới thường tồn tại lâu hơn, bạn có thể sử dụng chúng để yêu cầu mã thông báo truy cập mới sau khi mã thông báo truy cập có tuổi thọ ngắn hơn hết hạn.

Tuy nhiên, vì mã thông báo làm mới cũng là mã thông báo mang, chúng tôi cần phải có một chiến lược để hạn chế hoặc cắt giảm việc sử dụng chúng nếu chúng bị rò rỉ hoặc bị xâm phạm. Tất cả những người nắm giữ mã thông báo làm mới đều có quyền nhận mã thông báo truy cập mới bất cứ khi nào họ muốn. "Họ" có thể là người dùng hợp pháp hoặc kẻ tấn công.

Tại Auth0, chúng tôi đã tạo ra một tập hợp các tính năng giúp giảm thiểu rủi ro liên quan đến việc sử dụng mã thông báo làm mới bằng cách áp đặt các biện pháp bảo vệ và kiểm soát đối với vòng đời của chúng. Nền tảng nhận dạng của chúng tôi cung cấp xoay vòng mã thông báo làm mới, cũng đi kèm với tính năng phát hiện sử dụng lại tự động.

Hãy đi sâu hơn vào kỹ thuật bảo mật này.

Làm mới xoay vòng mã thông báo

Cho đến gần đây, một chiến lược mạnh mẽ để giúp các SPA duy trì phiên của người dùng là sử dụng Luồng mã ủy quyền với PKCE kết hợp với xác thực im lặng. Làm mới vòng quay mã thông báo là một kỹ thuật để nhận mã thông báo truy cập mới bằng cách sử dụng mã làm mới vượt ra ngoài xác thực im lặng .

Vòng quay mã thông báo làm mới đảm bảo rằng mỗi khi ứng dụng trao đổi mã thông báo làm mới để lấy mã thông báo truy cập mới, thì mã làm mới mới cũng được trả lại. Do đó, bạn không còn mã thông báo làm mới tồn tại lâu dài có thể cung cấp quyền truy cập bất hợp pháp vào tài nguyên nếu nó bị xâm phạm. Mối đe dọa về việc truy cập bất hợp pháp được giảm bớt khi các mã thông báo làm mới liên tục được trao đổi và mất hiệu lực.

Ví dụ: với tính năng xoay vòng mã thông báo làm mới được bật trong Bảng điều khiển Auth0, mỗi khi ứng dụng của bạn trao đổi mã thông báo làm mới để lấy mã thông báo truy cập mới, máy chủ ủy quyền cũng trả về một cặp mã thông báo truy cập làm mới mới. Biện pháp bảo vệ này giúp ứng dụng của bạn giảm thiểu các cuộc tấn công phát lại do các mã thông báo bị xâm phạm.

Làm mới mã thông báo tự động phát hiện sử dụng lại

Mã thông báo làm mới là mã thông báo không mang. Máy chủ ủy quyền không thể biết ai là hợp pháp hoặc độc hại khi nhận được yêu cầu mã thông báo truy cập mới. Sau đó, chúng tôi có thể coi tất cả người dùng là có khả năng độc hại.

Làm thế nào chúng ta có thể xử lý tình huống có điều kiện chạy đua giữa người dùng hợp pháp và người dùng độc hại? Ví dụ:

🐱 Người dùng hợp pháp🔄 Mã làm mới 1🔑 Mã truy cập 1 .

😈 Người dùng độc hại quản lý để đánh cắp 🔄 Làm mới mã thông báo 1 từ 🐱 Người dùng hợp pháp .

🐱 Người dùng hợp pháp sử dụng 🔄 Làm mới Mã thông báo 1 để nhận một cặp mã thông báo truy cập làm mới mới.

Các 🚓 Auth0 Authorization server nhuận 🔄 Refresh Mã 2🔑 access token 2 đến 🐱 hợp pháp tài .

😈 Người dùng độc hại sau đó cố gắng sử dụng 🔄 Làm mới mã thông báo 1 để nhận mã thông báo truy cập mới. Thuần ác!

Bạn nghĩ điều gì sẽ xảy ra tiếp theo? Would 😈 độc hại tài quản lý để nhận mã truy cập mới?

Đây là những gì sẽ xảy ra khi nền tảng danh tính của bạn có 🤖 Phát hiện tái sử dụng tự động :

Các 🚓 Auth0 Authorization máy chủ đã được lưu giữ theo dõi của tất cả các mã thông báo refresh giảm dần từ refresh dấu hiệu ban đầu. Đó là, nó đã tạo ra một "gia đình mã thông báo".

Các 🚓 Auth0 Authorization máy chủ nhận ra rằng ai đó đang tái sử dụng 🔄 Refresh Mã 1 và ngay lập tức làm mất hiệu lực gia đình thẻ làm mới, bao gồm 🔄 Refresh Mã 2 .

Các 🚓 Auth0 Authorization server trả về một Access Denied đối phó với 😈 độc hại tài .

🔑 Mã thông báo truy cập 2 hết hạn và 🐱 Người dùng hợp pháp cố gắng sử dụng 🔄 Mã thông báo làm mới 2 để yêu cầu một cặp mã thông báo truy cập làm mới mới.

Các 🚓 Auth0 Authorization server trả về một Access Denied đối phó với 🐱 hợp pháp tài .

Các 🚓 Auth0 Authorization máy chủ đòi hỏi phải tái thẩm định để có được truy cập mới và thẻ làm mới.

Điều quan trọng là mã làm mới được phát hành gần đây nhất phải bị vô hiệu ngay lập tức khi mã làm mới đã sử dụng trước đó được gửi đến máy chủ ủy quyền. Điều này ngăn không cho bất kỳ mã làm mới nào trong cùng một họ mã thông báo được sử dụng để nhận mã thông báo truy cập mới.

Cơ chế bảo vệ này hoạt động bất kể người dùng hợp pháp hay độc hại có thể trao đổi 🔄 Mã thông báo làm mới 1 để lấy cặp mã thông báo truy cập làm mới mới trước cặp mã kia. Nếu không thực thi ràng buộc người gửi, máy chủ ủy quyền không thể biết tác nhân nào là hợp pháp hoặc độc hại trong trường hợp tấn công phát lại.

Tự động phát hiện sử dụng lại là một thành phần chính của chiến lược xoay vòng mã thông báo làm mới. Máy chủ đã làm mất hiệu lực mã thông báo làm mới đã được sử dụng. Tuy nhiên, vì máy chủ ủy quyền không có cách nào để biết liệu người dùng hợp pháp có đang nắm giữ mã thông báo làm mới mới nhất hay không, nên nó sẽ làm mất hiệu lực toàn bộ họ mã thông báo chỉ để an toàn.

Làm mới mã thông báo giúp chúng tôi nắm bắt các công cụ bảo mật

Quyền riêng tư là một chủ đề nóng trong thế giới kỹ thuật số của chúng tôi. Chúng ta không chỉ cần cân bằng giữa bảo mật với tiện lợi mà còn cần thêm quyền riêng tư vào hành động cân bằng.

Những phát triển gần đây trong công nghệ bảo mật của trình duyệt, chẳng hạn như Ngăn chặn Theo dõi Thông minh (ITP), ngăn chặn quyền truy cập vào cookie phiên, yêu cầu người dùng xác thực lại.

Không có cơ chế lưu trữ liên tục nào trong một trình duyệt chỉ có thể đảm bảo quyền truy cập của ứng dụng đã định. Do đó, các mã thông báo làm mới tồn tại lâu dài không phù hợp với các SPA vì có những lỗ hổng mà người dùng độc hại có thể khai thác để lấy được các tạo tác có giá trị cao này, cấp cho họ quyền truy cập vào các tài nguyên được bảo vệ.

Vì xoay vòng mã thông báo làm mới không dựa vào quyền truy cập vào cookie phiên Auth0, nó không bị ảnh hưởng bởi ITP hoặc các cơ chế tương tự.

Tuy nhiên, mã thông báo làm mới có thể có tuổi thọ của nó bị giới hạn bởi tuổi thọ của mã thông báo truy cập. Điều này có nghĩa là chúng tôi có thể sử dụng mã làm mới một cách an toàn để chơi cùng với các công cụ bảo mật của trình duyệt và cung cấp quyền truy cập liên tục cho người dùng cuối mà không làm gián đoạn trải nghiệm người dùng.

Bạn có thể lưu trữ mã làm mới trong bộ nhớ cục bộ

Bạn đã đọc đúng. Khi chúng tôi có vòng quay mã thông báo làm mới tại chỗ, chúng tôi có thể lưu trữ mã thông báo trong bộ nhớ cục bộ hoặc bộ nhớ trình duyệt.

Bạn có thể đã nghe trước đây (có thể từ chúng tôi) rằng chúng tôi không nên lưu trữ mã thông báo trong bộ nhớ cục bộ.

Lưu trữ mã thông báo trong bộ nhớ cục bộ của trình duyệt cung cấp sự bền bỉ trên các lần làm mới trang và các tab trình duyệt; tuy nhiên, nếu người dùng độc hại quản lý để chạy JavaScript trong SPA bằng cách sử dụng cuộc tấn công tập lệnh trên nhiều trang web (XSS), họ có thể truy xuất mã thông báo được lưu trữ trong bộ nhớ cục bộ. Một lỗ hổng dẫn đến một cuộc tấn công XSS thành công có thể có trong mã nguồn SPA hoặc bất kỳ mã JavaScript nào của bên thứ ba mà ứng dụng sử dụng, chẳng hạn như Bootstrap hoặc Google Analytics.

Tuy nhiên, chúng tôi có thể giảm thời gian hết hạn tuyệt đối của mã thông báo để giảm rủi ro bảo mật khi lưu trữ mã thông báo trong bộ nhớ cục bộ. Điều này làm giảm tác động của một cuộc tấn công XSS được phản ánh (nhưng không phải là một cuộc tấn công dai dẳng). Mã thông báo làm mới có thể có tuổi thọ lâu dài theo cấu hình. Tuy nhiên, tuổi thọ dài được xác định của mã thông báo làm mới bị cắt ngắn với việc xoay vòng mã thông báo làm mới. Việc làm mới chỉ hợp lệ trong vòng đời của mã thông báo truy cập, sẽ tồn tại trong thời gian ngắn.

Sử dụng mã làm mới trong ứng dụng Auth0 của bạn

Nếu bạn quan tâm đến việc thêm xác thực và ủy quyền vào ứng dụng của mình chỉ trong vài bước, hãy đăng ký tài khoản Auth0 miễn phí ngay bây giờ .

Tài liệu "Các phương pháp hay nhất về mã thông báo " của chúng tôi nêu một số lưu ý cơ bản cần ghi nhớ khi sử dụng mã thông báo:

  • Giữ bí mật. Giữ nó an toàn.
  • Không thêm dữ liệu nhạy cảm vào tải trọng.
  • Cung cấp cho các mã thông báo hết hạn.
  • Nắm bắt HTTPS.
  • Xem xét tất cả các trường hợp sử dụng ủy quyền của bạn.
  • Lưu trữ và tái sử dụng.

Bảng điều khiển Auth0 giúp bạn dễ dàng định cấu hình các dịch vụ xác thực và ủy quyền để sử dụng mã thông báo làm mới. Các thư viện và SDK Auth0 hỗ trợ mã thông báo làm mới cho các ứng dụng web, Ứng dụng một trang (SPA) và ứng dụng gốc / ứng dụng dành cho thiết bị di động.

Nguồn: https://auth0.com

#jwt #auth0 #security #jwt 

davis mike

1626331037

Caching In WordPress: What You Need to Learn?

WordPress caching has nothing new to showcase in this context. WordPress websites also run on a specific server system and you have to make sure these servers work well for user engagement. So caching can help your website server work effectively to serve too many visitors collectively. The commonly requested items can be converted into varied copies that the website server doesn’t want to showcase every time to every website visitor. Classification of Caching is usually divided into two kinds. The Client-Side Caching & the Server Side Caching. Where client-side caching has nothing to do with your website, Server Side Caching is usually its opposite. Read more on https://bit.ly/3rbqvVh

#caching plugins #server side caching #client side caching #wordpress websites #wordpress caching

What is Distributed Caching

In this tutorial we are going to learn about what a cache is ? when we are going to use?, and How to use it? in a detailed manner.

So first of all,

What is a Cache?

Imagine that you have a system like this. Client Application request for some results from the server and the server asks those details form the Database. Then Database pullout the results to the Application server. Without pulling data from the Database all the time we can maintain another database/server to store data called Cache. Here there are 2 scenarios that you might want to use a cache.

  • When you requesting for a commonly used data, and every time we ask for those data we need to provide from the Database. Instead of this, you can save those commonly used data in a cache (in-memory cache). Here we can reduce network calls.
  • When you are doing a calculation by getting data from the database. You can reduce the number of calculations here. Store the result in cache and get the value from the cache without doing recomputations all the time. (Example: Assume you have a Student Management System and you need to calculate the average marks for a particular exam for a particular student. Store Average value in cache memory with key-value pair.)
  • We have all servers and they are hitting the database. It’s going to be a lot of loads. Instead of getting one cache, we can use more caches as a distributed system for Avoid load in the Database.

Can we store all the data in the cache?

No! We can’t store all the data in the cache because of multiple reasons.

  • The hardware that we use to make cache memories is much more expensive than a normal database.
  • If you store a ton of data on cache the search time will increase compared to the database.

So that now you know we can store infinite data on the database and we need to store the most valuable data in the cache.

When do you load data into the cache? When do you evict data from the cache?

Loading or Evicting data from the cache is called a Policy. So the cache performance depends on your cache policy. There are a number of policies you can have. The Most popular one is LRU(Least Recently Used).

**LRU **— you can add recently used entries to the bottom of the cache and least recently used entries go to the bottom. If you want to add new entries but the cache is almost full, then you can evict(kick) out those least recently used data.

Image for post

Some other Policies are,

  • Least Recently Used (LRU)
  • First In First Out (FIFO)
  • Random

#distributed-cache #caching-server #redis #caching

What is Bao Finance (BAO) | What is BAO token

Introducing Bao Finance

An innovative, fairly distributed, second layer for synthetic assets built on top of Uniswap, SushiSwap and Balancer.

Image for post

📖 Our Origin:

The global market for existing assets sits at a large $5.5T but has limited access and can only be built upon existing assets.

But imagine a world where anyone can trade any asset they can imagine.

With synthetic assets you can trade anything from a synthetic Chinese Yuan, a synthetic S&P500 or any number of newly created assets.

Perhaps you want to create an asset tied to the value of the United States Unemployment Report, or the number of Big Macs that McDonald’s sells each year in Peru.

This is all possible when creating synthetic assets.

❓ Challenges with Existing Synthetics:

Today, some synthetic protocols already exist such as Synthetix and UMA. While they are early stage, they have amassed a marketcap of over >$1B combined showing the size of the addressable market.

We think both Synthetix and UMA are promising technologies in this space that have their place, we just have philosophical differences on how to best solve the challenges of synthetic assets.

Each of these existing protocols suffer from at least a few of these key risks:

  1. They require the use of their asset to underpin the issuance of the synthetic. This means the synthetics are overly tied in risk to a single asset.
  2. They are an adversarial money lock-up. In order to put your money into a synthetic asset, you cannot be using it elsewhere.
  3. In some cases (UMA) they also require the use of custom oracles that involve human arbitration.

In the grand scheme, neither Synthetic or UMA have issued that many synthetic assets.

If they can reach a combined marketcap of >$1b with these challenges, imagine what we can do by trying a new approach?

💻 Designing Our Protocol:

Bao will create what we call a “Second-Layer” protocol.

This is because rather than design Bao to be deposited into directly, we’ll build out our features to work in existing systems.

Users will use assets from Uniswap and soon SushiSwap and Balancer to take part in the Bao ecosystem.

We view ourselves as the first L2 DeFi, aiming to add our protocol’s features on-top of existing infrastructure.

Within Bao, users will be able to create synthetic assets by using their LP tokens from other protocols:

Image for post

In this example a user deposits their wBTC and ETH into a Uniswap pool and receives the wBTC/ETH UNIV2-LP token in return.

They use that wBTC/ETH UNIV2-LP token as collateral in Bao.Finance.

When they deposit collateral into Bao.Finance they earn Bao tokens, which are used as a portion of collateral (10%).

They can then generate synthetic assets up to their collateral limit by burning a small fee in Bao tokens.

In this model the user can:

  • Earn fees from being an LP in Uniswap/SushiSwap/Balancer.
  • Earn yield rewards from being an LP in Uniswap/SushiSwap/Balancer pools.
  • Earn yield rewards in $Bao by staking their LP tokens as collateral.
  • And, issue synthetic assets to invest in other assets with that same money.

These creates powerful opportunities for users to do things like:

  • Open a leveraged position on any DeFi asset.
  • Create robust synthetic assets for any type of market.
  • Hold a USDb stablecoin that still generates yield from their underlying collateral.

💸 Token Distribution:

To begin prior to the launch of the ability to issue synthetic assets, $Bao will use the yield distribution model created by YAM and Sushiswap to distribute $Bao tokens.

Starting with block 11420726 ( https://etherscan.io/block/countdown/11420726) you will be able to stake Uniswap V2-LP tokens on  https://bao.finance

The staking covers over 200 pools from diverse assets, covering both old and new projects with large and small marketcaps, hopefully allowing one of the most broad distributions in the history of yield farming. The specific weighting of each pool can be found here:  https://docs.bao.finance/pool-weights

Each block on the Ethereum blockchain will distribute a base of 1000 $Bao tokens across the pools following a proportional weighted distribution.

During the first two year period, there will also be a weekly rewards modifier to incentivize early participation and combat reward fatigue and inflation. The specific model for each week can be found here:  https://docs.bao.finance/distribution-tokenomics

This distribution will continue overtime until there are 1T $Bao tokens issued:

Image for post

$Bao’s token issuance is high as we expect rapid burning and locking to take place when the synthetic asset component of Bao’s ecosystem launches.

There is also a manual mint issuance of 74b tokens which rounds out the final number to 1T.

This number represents less than 28% of the first week of token issuance (260B) and will be used over the first 6 months as rewards and payments for liquidity providers, exchange listings, audits, user/community rewards, and bounties for key community sites and documentation.

The first 1B allocation will be added as liquidity on Uniswap to start, allowing users to acquire $Bao at the start so they can begin using the $Bao/ETH pool right at the start of yield farming, and to take part in any governance votes the community needs before the start of the yield farming phase.

A max of 3.25b of that can be allocated each week in order to prevent it from over diluting the farming rewards.

When those rewards are paid to partners for liquidity, listings, audits or community rewards, they will be streamed out over time either in manual quarterly chunks or via Sablier.Finance — we expect that the full 72B tokens when allocated will not reach circulation before the end of the 2nd year.

🔐 Locking Function:

During the yield farming period when users earn their $Bao and harvest it, they’ll instantly receive 5% of the $Bao they’ve accumulated.

The remaining 95% of their $Bao will be locked to their address. That user will own the $Bao in the token contract, but will only be able to have it as a usable balance once it unlocks.

The 95% balance will unlock in a linear fashion over a 3 year time period, after the first year.

This means 53 weeks after the launch of Bao the user will receive a daily grant of $Bao tokens.

Image for post

An oraclized widget on the Bao.finance site will allow the user to see their locked Bao, know its current worth in USD, and get estimates on the daily and annual unlock amounts.

This long term lockup insures that incentives are aligned with community members long-term and prevents the risk of being dumped on or optimizing for short-term gain.

The founder’s allocation is locked on the same 95% 3-year vest schedule as the community. This prevents the kind of disaster that SushiSwap had.

💰 The Treasury:

The Bao Treasury consists of a few components:

  • Fees collected
  • Dev/Bounty Fund (6% of issuance)
  • The Liquidity Provider Fund (4% of issuance)
  • The Community Fund (6% of issuance)

Other than the fees collected, the funds are also locked and distributed in a linear fashion over the 3 year period.

The treasury also backs the token, while users can vote to distribute the treasury to token holders, in the event the project shuts down or is unsuccessful the treasury would be distributed to the Bao holders. Creating a safe backstop for the project value, where the worst case scenario for $Bao is being the best broad index exposure to DeFi.

For the fees Bao.Finance system carries some basic deposit/withdraw fees, as well as behavioral penalties.

In V1:

Users will pay a 0.75% deposit fee on their LP token deposits, which will ultimately be offset by the upside APY that the user earns.

The user also has a withdrawal fee based on how long they’ve been in the pools. They are divided into two portions “Standard Fees”, “Penalty Fees” and “Slashing Penalty”

The standard fees are:

  • 0.5% for withdrawing after 5 days but before 2 weeks.
  • 0.25% for withdrawing after 2 weeks but before 4 weeks.
  • 0.1% for withdrawing after 4 weeks.

The penalty fees are:

  • 1% fee if a user withdraws under 5 days
  • 2% fee if a user withdraws under 3 days.
  • 4% fee if a user withdraws under 1 day.
  • 8% fee if a user withdraws under 1 hour.

The slashing penalty is:

  • 25% slashing fee if the user withdraws within the same block. This penalty is designed to prevent any attempt at flash loan exploits and will not ever be able to impact normal users.

These fees collected allow the treasury to be diverse and in multiple assets and force users to align with longer-term incentives. Users who only want to use the protocol short term are deterred and forced to decide on the fee trade-offs.

V2:

In our V2 when synthetic asset issuance is launched, the treasury acts as an insurance fund against liquidations and backing the assets.

By having the fees collected in multiple types of token, we’ve created a system that is secure against flash crashes.

For example, if in the Synthetix ecosystem SNX was to have a devastating market crash, it would lead to liquidations and asset volatility across all of their assets.

With our treasury/insurance fund being broadly held across multiple assets, and user collateral being held across multiple assets, one-type of collateral can entirely fail and the ecosystem can still be secure and stable.

For V2, users will pay a burn fee in Bao when they issue or redeem synthetic assets, on top of the regular fees for depositing or withdrawing collateral.

V2 will also offer a DEX exchange for trading synthetic assets which will carry a standard trading fee model. These fees will be added to the treasury.

💴 Additional Rewards:

The Bao.finance site also links to various exchanges via referral links for users to acquire those tokens.

When signing up with these links, any trades a user performs on these exchanges will create an affiliate bonus paid out to Bao.Finance — each month we will add 100% of these collected fees to the treasury that backs the $Bao token.

Even if users already have an account with that exchange, they can create a new one via our affiliate links to drive additional revenue to Bao which essential acts as a rebate for the users indirectly.

💵 Founders Reward:

The founder also has a 4% founders fund that they earn paid in $Bao. This fund has 95% of fees locked and vested over the same 3-year linear model as user fees.

📊 User Voting & Governance:

The entire system for $Bao is built in a modular fashion where nearly all numbers in the systems are variables.

This allows for a significant portion of the protocol to be modified by the users at anytime.

We view that the protocol, funds and system are owned by the community and not by the Bao team.

To start,  BaoMan (the founder) will be appointed as the first administrator of the protocol, responsible for its maintenance and care. He will enact the changes that users vote on and manage the governance process.

However, through the governance process the users can decide almost anything such as:

  • Changing all the reward rates.
  • Changing or removing fees.
  • Changing or removing founder rewards.
  • Changing fee rates or timelines.
  • Changing supported pools and allocations.
  • Removing BaoMan and electing new administrators.
  • Deciding which products to build and prioritize.

In theory, once $Bao begins to circulate, users could vote to remove BaoMan, not create a synthetic protocol and use the treasury for other purposes under new leadership.

The specific inner workings of the governance model are outlined here: https://docs.bao.finance/governance-mandates

🔪 The Chopping Block:

Each week, new pools are added to “The Chopping Block” — these are pools that are under performing based on their TLV or the percent of Uniswap LP tokens locked in that pool.

The pools will be warned each Sunday that they are on the chopping block, and will have until Tuesday to encourage their community to get them off the chopping block by increasing their participation.

As of Wednesday, The Chopping Block will be sealed for that week.

The pools will be put up for a vote, the top 50% of pools who get voted to be saved will remain, the other 50% of pools will have their reward weight set to 0 and will be removed from the Bao.finance yield farming.

This means that as pools get removed, the rewards earned for pools that remain will increase. By increasing these rewards each week, it offsets some of the declining reward rates.

This will continue until there is a certain amount of remaining pools or the V2 is fully launched.

More details on the chopping block can be found here:  https://docs.bao.finance/chopping-block

🎉 How to Join In:

You can find the app at  https://www.bao.finance and begin staking your tokens for the start of distributions at block 11,420,726

You can also join our Discord at:  https://discord.gg/BW3P62vJXT

And follow @TheBaoMan on Twitter for updates.

Finally you can read the docs at  https://docs.bao.finance/

❕ Note: Bao.finance is a high-risk project in Alpha. It is community governed and unaudited. It also includes a fee structure. If you have any concerns about long-term participation, technical or economic risk, or fees, then you shouldn’t partake in Bao.

Would you like to earn BAO right now! ☞ CLICK HERE

Looking for more information…

☞ Website
☞ Explorer
☞ Social Channel
Message Board
☞ Coinmarketcap

Create an Account and Trade Cryptocurrency NOW

Binance
Bittrex
Poloniex

Thank for visiting and reading this article! I’m highly appreciate your actions! Please share if you liked it!

#blockchain #bitcoin #bao finance #bao

Duong Tran

Duong Tran

1633159260

Ba tính năng mới của Next.js và cách sử dụng chúng

AWS Amplify gần đây đã thêm hỗ trợ cho Next.js 10 tính năng, bao gồm tái tạo tĩnh gia tăng, tùy chọn bắt tất cả các tuyến đường và tối ưu hóa hình ảnh. Trong bài đăng này, chúng ta sẽ tìm hiểu từng tính năng này là gì, cách triển khai ứng dụng fullstack bằng cách sử dụng chúng và cách triển khai chúng lên AWS! Hãy đi sâu vào.

Xin lưu ý rằng tôi làm việc với tư cách là Người ủng hộ nhà phát triển trong nhóm AWS Amplify, nếu bạn có bất kỳ phản hồi hoặc câu hỏi nào về vấn đề này, vui lòng liên hệ với tôi hoặc hỏi trên Discord - discord.gg/amplify của chúng tôi!

Nếu bạn mới sử dụng Next.js, hãy xem hướng dẫn này trước để bắt đầu! Tôi cũng đã viết hướng dẫn này về cách tạo ứng dụng Next.js fullstack nếu bạn muốn kiểm tra điều đó.

Cài đặt

Đầu tiên, hãy tạo một ứng dụng Next.js:

npx create-next-app next10-blog

Bây giờ, hãy tạo phần phụ trợ ứng dụng của chúng tôi. Đi tới Hộp cát Khuếch đại và sau đó "bắt đầu". Chọn "dữ liệu" trên trang tiếp theo và bắt đầu với lược đồ blog.

dữ liệu được chọn với lược đồ blog

Tôi đã xóa mô hình "Blog" và thêm trường "nội dung" vào mô hình Bài đăng.

Sau đó, bạn có thể bỏ qua trang "Kiểm tra cục bộ trong ứng dụng của bạn" và chuyển thẳng đến việc triển khai với tài khoản AWS của mình. Làm theo các bước hướng dẫn để triển khai ứng dụng của bạn!

Sau khi chương trình phụ trợ của bạn đã được triển khai, hãy nhập Giao diện người dùng quản trị cho ứng dụng của bạn rồi nhấp vào "Hướng dẫn thiết lập cục bộ" ở trên cùng bên phải. Chạy lệnh kéo Amplify vào ứng dụng Tiếp theo mà bạn đã tạo. Ngoài ra, hãy cài đặt các thư viện AWS Amplify cũng như TypeScript - bạn không cần TypeScript cho mã của mình, nó chỉ dành cho các mô hình DataStore đã tạo.

amplify pull --appId your-appID --envName staging
npm install aws-amplify typescript

Tôi cũng sẽ tạo một số bài đăng trên blog cho ứng dụng của mình. Nhấp vào "Quản lý nội dung ứng dụng" trong Giao diện người dùng quản trị Amplify. Trong menu thả xuống "Tác vụ", bạn sẽ thấy tùy chọn "Tự động tạo dữ liệu". Hãy tiếp tục và tạo 10 bài đăng trên blog. Bạn sẽ thấy tiêu đề và mô tả bật lên!

Bây giờ là thời gian mã! Mở ứng dụng Next.js mà bạn đã tạo vài bước trước. Mở tệp _app.js và quảng cáo như sau. Điều này sẽ giúp các thư viện giao diện người dùng của Amplify tự động được liên kết với các tài nguyên phụ trợ mà bạn đã tạo! Chúng tôi cũng sẽ bật hiển thị phía máy chủ.

import Amplify from 'aws-amplify'
import awsconfig from '../src/aws-exports'
Amplify.configure({ ...awsconfig, ssr: true })

Bây giờ, chúng tôi sẽ thực hiện index.jslộ trình - trang chủ này sẽ liệt kê tất cả các bài đăng trên blog của chúng tôi và liên kết chúng với một trang phụ sẽ hiển thị một bài đăng. Chúng tôi sẽ sử dụng SSR cho tuyến đường này.

Đầu tiên, tôi sẽ nhập mô hình dữ liệu của mình từ src/modelsthư mục đã tạo . Tôi cũng sẽ nhập withSSRContexthàm từ Amplify - điều này sẽ cho phép chúng tôi chạy truy vấn của mình ở phía máy chủ.

import { withSSRContext } from 'aws-amplify'
import { Post } from '../src/models'

Bây giờ, hãy tạo một hàm getServerSideProps . Sau đó, chúng tôi sẽ cho phép Amplify chạy trên máy chủ withSSRContext, chúng tôi cũng sẽ cung cấp cho nó thông tin yêu cầu. Sau đó, chúng tôi sẽ chạy một truy vấn để nhận tất cả các bài đăng trên blog của chúng tôi! Cuối cùng, chúng ta sẽ trả về một đối tượng cung cấp các mô hình của chúng ta làm đạo cụ! Bạn có thể chuyển đổi sang JSON theo cách thủ công hoặc sử dụng serializeModelchức năng từ Amplify.

export async function getServerSideProps (context) {
  const SSR = withSSRContext(context.req)
  const models = await SSR.DataStore.query(Post)

  return {
    props: {
      models: JSON.parse(JSON.stringify(models))
    }
  }
}

Bây giờ chúng ta có thể lập bản đồ thông qua các bài đăng và hiển thị chúng trên trang!

export default function Home ({ posts }) {
  return (
    <div>
      <Head>
        <title>Amplify + Next</title>
        <meta name='description' content='Amplify + Next!' />
      </Head>

      <main>
        {posts.map(post => (
          <div key={post.id}>
            <a href={`/post/${post.id}`}>
              <h2>{post.title}</h2>
            </a>
          </div>
        ))}
      </main>
    </div>
  )
}

ISR

Bây giờ chuyển sang 10 tính năng mới của Tiếp theo! Đầu tiên, chúng tôi sẽ triển khai ISR ​​hoặc tái tạo tĩnh gia tăng. Thông thường, khi bạn sử dụng tạo trang web tĩnh , trang web sẽ xây dựng một lần khi bạn triển khai ứng dụng của mình. Nhưng trong nhiều trường hợp, bạn muốn các trang tĩnh của mình cập nhật khi dữ liệu của bạn thay đổi. ISR cho phép điều đó - bạn cung cấp thời gian xác thực lại chogetStaticPropsvà sau đó khi đạt đến khoảng thời gian đó, trang sẽ được tạo lại. Về cơ bản, các trang được tạo tĩnh ban đầu và những người dùng đầu tiên truy cập trang trước thời gian tái tạo được cung cấp sẽ được phục vụ trang web được tạo tĩnh đó. Sau đó, yêu cầu tiếp theo đến trang đó sau khi thời gian tái tạo được nhấn sẽ kích hoạt trang xây dựng lại trong nền - người dùng đã kích hoạt tái tạo sẽ được cung cấp phiên bản cũ của trang nhưng những người dùng tiếp theo nhận được phiên bản mới. Điều này đặc biệt hữu ích trong các tình huống thương mại điện tử và trong trường hợp của chúng tôi, một blog mà bạn không cần phải triển khai lại mỗi khi bạn muốn thêm một bài đăng mới!

Chúng tôi sẽ tạo một trang hiển thị một bài đăng trên blog. Đầu tiên, chúng tôi sẽ tạo một post/[post].jsthành phần trang trong /pages/thư mục. Hãy bắt đầu với các nhập mà chúng ta cần.

import { withSSRContext } from 'aws-amplify'
import { useRouter } from 'next/router'

import { Post } from '../../src/models'

Bây giờ, chúng ta sẽ tạo một getStaticPathshàm tạo một trang tĩnh cho mỗi bài đăng. Chúng tôi sẽ truy vấn tất cả các bài đăng của mình, lập bản đồ qua chúng và sau đó trả lại chúng từ hàm. Chúng tôi cũng sẽ cung cấp một fallback: trueở đây sẽ làm cho nó để thay vì đưa ra ngay lập tức 404 khi một tuyến đường không được tạo gặp phải, Next.js thay vào đó sẽ thử và tạo trang trong nền và sau đó hiển thị nó.

export async function getStaticPaths() {
  const SSR = withSSRContext()
  const posts = await SSR.DataStore.query(Post)
  const paths = posts.map(post => ({
    params: { post: post.id }
  }))

  return {
    paths, fallback: true
  }
}

Bây giờ, chúng tôi sẽ thực hiện của chúng tôi getStaticProps. Lần này chúng tôi sẽ truy vấn chỉ một bài đăng bằng cách sử dụng id của nó. Sau đó, chúng tôi sẽ trả lại bài đăng trong đối tượng đạo cụ và chúng tôi cũng sẽ thêm revalidatekhóa. Điều này sẽ triển khai ISR ​​cho trang của chúng tôi! Tôi sẽ cung cấp 10 sẽ làm cho thời gian xác thực lại là 10 giây. Bạn có thể thay đổi giá trị này tùy thuộc vào trường hợp sử dụng của mình!

export async function getStaticProps(context) {
  const SSR = withSSRContext(context.req)
  const post = await SSR.DataStore.query(Post, context.params.post)
  return {
    props: {
      post: JSON.parse(JSON.stringify(post))
    },
    revalidate: 10
  }
}

Bây giờ, chúng tôi sẽ hiển thị bài đăng trên trang! Tôi sẽ sử dụng router.isFallbackđể hiển thị chỉ báo tải nếu một đường dẫn không được tạo bị đánh - Tôi chỉ làm điều này vì tôi đã sử dụng fallback: true!

export default function PostPage({ post }) {
  const router = useRouter()

  if (router.isFallback) {
    return <div>Loading...</div>
  }

  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>
    </div>
  )
}

Sau đó, tôi sẽ đẩy mã của mình lên GitHub. Sau đó, tôi sẽ quay lại trang Bảng điều khiển AWS cho ứng dụng của mình. Bạn sẽ thấy backend environmentstrang được điền bằng liên kết Giao diện người dùng quản trị của mình. Đi tới frontend environmentstab và bạn sẽ có tùy chọn để triển khai ứng dụng của mình!

Làm theo các bước triển khai được hướng dẫn, bạn sẽ có thể chọn chi nhánh của mình từ GitHub và sử dụng các tập lệnh xây dựng mặc định được phát hiện từ package.json của bạn! Bạn cũng sẽ thấy thông tin về những gì đã được triển khai - trong trường hợp này, bạn sẽ có một hàm Lambda @ Edge sẽ xử lý ISR ​​cho bạn!

Bắt tất cả các tuyến đường tùy chọn

Chúng tôi có hai tính năng nhanh hơn nhiều để trò chuyện, tùy chọn đầu tiên là bắt tất cả các tuyến đường. Những điều này cho phép bạn tạo một tuyến đường có thể có bất kỳ tham số nào sau nó. Chúng tôi sẽ tạo một trang cho trang giới thiệu. /aboutnên hiển thị trang, nhưng nên /about/hi/about/ali/spittel. Chúng ta có thể làm điều này bằng cách tạo một thành phần trang, sau đó đặt nó trong dấu ngoặc kép và thêm ba dấu chấm vào trước nó.

Đầu tiên, tạo tệp cho trang:

/pages/about/[[...about.js]]

Bây giờ, tôi sẽ triển khai compnent. Tôi sẽ sử dụng useRoutertừ Tiếp theo để nhận thông tin về tuyến đường, sau đó tôi sẽ hiển thị các thông số tuyến đường trên trang! Hãy thử /about, /about/hi/about/ali/spittelvà xem cách này thay đổi!

import { useRouter } from 'next/router'
import React from 'react'

export default function About(props) {
  const routeData = useRouter()
  return (
    <div>
      {JSON.stringify(routeData.query)}
    </div>
  )
}

Bây giờ hãy đẩy mã của bạn lên GitHub và Amplify sẽ tự động triển khai lại giao diện người dùng của bạn với trang giới thiệu mới!

Thành phần hình ảnh

Cuối cùng, chúng ta hãy thử các Next.js Imagethành phần . Thành phần này tự động cho phép tối ưu hóa hình ảnh bằng cách thay đổi kích thước, tối ưu hóa và cung cấp các loại hình ảnh khác nhau như webp khi trình duyệt hỗ trợ chúng. Tôi đã thêm ảnh con chó Blair của mình vào thư mục / public.

Sau đó, tôi đã nhập Imagethành phần trong index.jstệp

import Image from 'next/image'

Sau đó, tôi kết xuất hình ảnh của cô ấy trên trang!

 <Image src='/blair.jpeg' alt='Fluffy white dog lying on a couch' height={200} width={150} />

Tôi lại đẩy sang GitHub để triển khai lại trang web!

Kết luận

Tôi hy vọng hướng dẫn này đã giúp bạn triển khai một số tính năng Next.js mới và triển khai chúng cho AWS Amplify. Nếu bạn muốn gỡ ứng dụng của mình xuống, bạn có thể chạy amplify deletetừ CLI của mình và mã của bạn sẽ tồn tại cục bộ nhưng nó sẽ không được triển khai lên đám mây nữa. Nếu bạn có bất kỳ phản hồi nào về AWS Amplify hoặc hướng dẫn này, vui lòng cho tôi biết!

 

#next #nextjs #react #webdev