前后端常見的幾種鑒權(quán)方式(小結(jié))
最近在重構(gòu)公司以前產(chǎn)品的前端代碼，擯棄了以前的session-cookie鑒權(quán)方式，采用token鑒權(quán)，忙里偷閑覺得有必要對幾種常見的鑒權(quán)方式整理一下。
目前我們常用的鑒權(quán)有四種：
HTTP Basic Authentication
session-cookie
Token 驗(yàn)證
OAuth(開放授權(quán))
一.HTTP Basic Authentication
這種授權(quán)方式是瀏覽器遵守http協(xié)議實(shí)現(xiàn)的基本授權(quán)方式,HTTP協(xié)議進(jìn)行通信的過程中，HTTP協(xié)議定義了基本認(rèn)證認(rèn)證允許HTTP服務(wù)器對客戶端進(jìn)行用戶身份證的方法。
認(rèn)證過程：
1． 客戶端向服務(wù)器請求數(shù)據(jù)，請求的內(nèi)容可能是一個(gè)網(wǎng)頁或者是一個(gè)ajax異步請求，此時(shí)，假設(shè)客戶端尚未被驗(yàn)證，則客戶端提供如下請求至服務(wù)器:
Get /index.html HTTP/1.0
Host:www.google.com
2． 服務(wù)器向客戶端發(fā)送驗(yàn)證請求代碼401,（WWW-Authenticate: Basic realm=”google.com”這句話是關(guān)鍵，如果沒有客戶端不會彈出用戶名和密碼輸入界面）服務(wù)器返回的數(shù)據(jù)大抵如下：
HTTP/1.0 401 Unauthorised
Server: SokEvo/1.0
WWW-Authenticate: Basic realm=”google.com”
Content-Type: text/html
Content-Length: xxx
3． 當(dāng)符合http1.0或1.1規(guī)范的客戶端（如IE，F(xiàn)IREFOX）收到401返回值時(shí)，將自動彈出一個(gè)登錄窗口，要求用戶輸入用戶名和密碼。
4． 用戶輸入用戶名和密碼后，將用戶名及密碼以BASE64加密方式加密，并將密文放入前一條請求信息中，則客戶端發(fā)送的第一條請求信息則變成如下內(nèi)容：
Get /index.html HTTP/1.0
Host:www.google.com
Authorization: Basic d2FuZzp3YW5n
注：d2FuZzp3YW5n表示加密后的用戶名及密碼（用戶名：密碼 然后通過base64加密，加密過程是瀏覽器默認(rèn)的行為，不需要我們?nèi)藶榧用埽覀冎恍枰斎胗脩裘艽a即可）
5． 服務(wù)器收到上述請求信息后，將Authorization字段后的用戶信息取出、解密，將解密后的用戶名及密碼與用戶數(shù)據(jù)庫進(jìn)行比較驗(yàn)證，如用戶名及密碼正確，服務(wù)器則根據(jù)請求，將所請求資源發(fā)送給客戶端
效果：
客戶端未未認(rèn)證的時(shí)候，會彈出用戶名密碼輸入框，這個(gè)時(shí)候請求時(shí)屬于pending狀態(tài)，這個(gè)時(shí)候其實(shí)服務(wù)當(dāng)用戶輸入用戶名密碼的時(shí)候客戶端會再次發(fā)送帶Authentication頭的請求。
認(rèn)證成功：
server.js
let express = require("express");
let app = express();
app.use(express.static(__dirname+'/public'));
app.get("/Authentication_base",function(req,res){
console.log('req.headers.authorization:',req.headers)
if(!req.headers.authorization){
res.set({
'WWW-Authenticate':'Basic realm="wang"'
});
res.status(401).end();
}else{
let base64 = req.headers.authorization.split(" ")[1];
let userPass = new Buffer(base64, 'base64').toString().split(":");
let user = userPass[0];
let pass = userPass[1];
if(user=="wang"&&pass="wang"){
res.end("OK");
}else{
res.status(401).end();
}
}
})
app.listen(9090)
index.html:
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>HTTP Basic Authentication</title>
</head>
<body>
<div></div>
<script src="js/jquery-3.2.1.js"></script>
<script>
$(function(){
send('./Authentication_base');
})
var send = function(url){
$.ajax({
url : url,
method : 'GET',
});
}
</script>
</body>
</html>
當(dāng)然有登陸就有注銷，我們會發(fā)現(xiàn)當(dāng)我們認(rèn)證成功后每次請求請求頭都會帶上Authentication及里面的內(nèi)容，那么如何做到讓這次登陸失效的？
網(wǎng)上查了半天，目前最有效的方式就是在注銷操作的時(shí)候，專門在服務(wù)器設(shè)置一個(gè)專門的注銷賬號，當(dāng)接收到的Authentication信息為注銷用戶名密碼的時(shí)候糾就帶便注銷成功了，而客戶端在注銷操作的時(shí)候，手動的的去修改請求頭重的Authentication，將他設(shè)置未服務(wù)器默認(rèn)的注銷賬號和密碼。
通過上面的簡單講解 其實(shí)我們已經(jīng)可以返現(xiàn)這種驗(yàn)證方式的缺陷加密方式簡單，僅僅是base64加密，這種加密方式是可逆的。同時(shí)在每個(gè)請求的頭上都會附帶上用戶名和密碼信息，這樣在外網(wǎng)是很容易被嗅探器探測到的。
總結(jié):
正式因?yàn)檫@樣，這種加密方式一般多被用在內(nèi)部安全性要求不高的的系統(tǒng)上，只是相對的多，總的來說現(xiàn)在使用這種鑒權(quán)比較少了。如果項(xiàng)目需要部署在公網(wǎng)上，這種方式不推薦，當(dāng)然你也可以和SSL來加密傳輸，這樣會好一點(diǎn)，這個(gè)如果我后面有時(shí)間來研究一下。
二.session-cookie
第二種這個(gè)方式是利用服務(wù)器端的session（會話）和瀏覽器端的cookie來實(shí)現(xiàn)前后端的認(rèn)證，由于http請求時(shí)是無狀態(tài)的，服務(wù)器正常情況下是不知道當(dāng)前請求之前有沒有來過，這個(gè)時(shí)候我們?nèi)绻涗洜顟B(tài)，就需要在服務(wù)器端創(chuàng)建一個(gè)會話(seesion),將同一個(gè)客戶端的請求都維護(hù)在各自得會會話中，每當(dāng)請求到達(dá)服務(wù)器端的時(shí)候，先去查一下該客戶端有沒有在服務(wù)器端創(chuàng)建seesion，如果有則已經(jīng)認(rèn)證成功了，否則就沒有認(rèn)證。
session-cookie認(rèn)證主要分四步：
1，服務(wù)器在接受客戶端首次訪問時(shí)在服務(wù)器端創(chuàng)建seesion，然后保存seesion(我們可以將seesion保存在內(nèi)存中，也可以保存在redis中，推薦使用后者)，然后給這個(gè)session生成一個(gè)唯一的標(biāo)識字符串,然后在響應(yīng)頭中種下這個(gè)唯一標(biāo)識字符串。
2.簽名。這一步只是對sid進(jìn)行加密處理，服務(wù)端會根據(jù)這個(gè)secret密鑰進(jìn)行解密。（非必需步驟）
3.瀏覽器中收到請求響應(yīng)的時(shí)候會解析響應(yīng)頭，然后將sid保存在本地cookie中，瀏覽器在下次http請求de 請求頭中會帶上該域名下的cookie信息，
4.服務(wù)器在接受客戶端請求時(shí)會去解析請求頭cookie中的sid，然后根據(jù)這個(gè)sid去找服務(wù)器端保存的該客戶端的session，然后判斷該請求是否合法。
server.js(nodejs+express+seesion+redis)
var express = require('express');
var RedisStore = require('connect-redis')(express.session);
var app = express();
var secret = "wang839305939"
// 設(shè)置 Cookie
app.use(express.cookieParser(secret));
// 設(shè)置 Session
app.use(express.session({
store: new RedisStore({
host: "127.0.0.1",
port: 6379,
db: "session_db"
}),
secret: secret
}))
app.get("/", function(req, res) {
var session = req.session;
session.time= session.time|| 0;
var n = session.time++;
res.send('hello, session id:' + session.id + ' count:' + n);
});
app.listen(9080);
三.Token 驗(yàn)證
使用基于 Token 的身份驗(yàn)證方法，大概的流程是這樣的：
1. 客戶端使用用戶名跟密碼請求登錄
2. 服務(wù)端收到請求，去驗(yàn)證用戶名與密碼
3. 驗(yàn)證成功后，服務(wù)端會簽發(fā)一個(gè) Token，再把這個(gè) Token 發(fā)送給客戶端
4. 客戶端收到 Token 以后可以把它存儲起來，比如放在 Cookie 里或者 Local Storage 里
5. 客戶端每次向服務(wù)端請求資源的時(shí)候需要帶著服務(wù)端簽發(fā)的 Token
6. 服務(wù)端收到請求，然后去驗(yàn)證客戶端請求里面帶著的 Token，如果驗(yàn)證成功，就向客戶端返回請求的數(shù)據(jù)
總的來說就是客戶端在首次登陸以后，服務(wù)端再次接收http請求的時(shí)候，就只認(rèn)token了，請求只要每次把token帶上就行了，服務(wù)器端會攔截所有的請求，然后校驗(yàn)token的合法性，合法就放行，不合法就返回401（鑒權(quán)失敗）。
乍的一看好像和前面的seesion-cookie有點(diǎn)像，seesion-cookie是通過seesionid來作為瀏覽器和服務(wù)端的鏈接橋梁，而token驗(yàn)證方式貌似是token來起到seesionid的角色。其實(shí)這兩者差別是很大的。
1. sessionid 他只是一個(gè)唯一標(biāo)識的字符串，服務(wù)端是根據(jù)這個(gè)字符串，來查詢在服務(wù)器端保持的seesion，這里面才保存著用戶的登陸狀態(tài)。但是token本身就是一種登陸成功憑證，他是在登陸成功后根據(jù)某種規(guī)則生成的一種信息憑證，他里面本身就保存著用戶的登陸狀態(tài)。服務(wù)器端只需要根據(jù)定義的規(guī)則校驗(yàn)這個(gè)token是否合法就行。
2. session-cookie是需要cookie配合的，居然要cookie，那么在http代理客戶端的選擇上就是只有瀏覽器了，因?yàn)橹挥袨g覽器才會去解析請求響應(yīng)頭里面的cookie,然后每次請求再默認(rèn)帶上該域名下的cookie。但是我們知道http代理客戶端不只有瀏覽器，還有原生APP等等，這個(gè)時(shí)候cookie是不起作用的，或者瀏覽器端是可以禁止cookie的(雖然可以，但是這基本上是屬于吃飽沒事干的人干的事)?，但是token 就不一樣，他是登陸請求在登陸成功后再請求響應(yīng)體中返回的信息，客戶端在收到響應(yīng)的時(shí)候，可以把他存在本地的cookie,storage，或者內(nèi)存中，然后再下一次請求的請求頭重帶上這個(gè)token就行了。簡單點(diǎn)來說cookie-session機(jī)制他限制了客戶端的類型，而token驗(yàn)證機(jī)制豐富了客戶端類型。
3. 時(shí)效性。session-cookie的sessionid實(shí)在登陸的時(shí)候生成的而且在登出事時(shí)一直不變的，在一定程度上安全就會低，而token是可以在一段時(shí)間內(nèi)動態(tài)改變的。
4. 可擴(kuò)展性。token驗(yàn)證本身是比較靈活的，一是token的解決方案有許多，常用的是JWT,二來我們可以基于token驗(yàn)證機(jī)制，專門做一個(gè)鑒權(quán)服務(wù)，用它向多個(gè)服務(wù)的請求進(jìn)行統(tǒng)一鑒權(quán)。
下面就拿最常用的JWT（JSON WEB TOKEN）來說：
JWT是Auth0提出的通過對JSON進(jìn)行加密簽名來實(shí)現(xiàn)授權(quán)驗(yàn)證的方案，就是登陸成功后將相關(guān)信息組成json對象，然后對這個(gè)對象進(jìn)行某中方式的加密，返回給客戶端，客戶端在下次請求時(shí)帶上這個(gè)token，服務(wù)端再收到請求時(shí)校驗(yàn)token合法性，其實(shí)也就是在校驗(yàn)請求的合法性。
JWT對象通常由三部分構(gòu)成：
Headers： 包括類別（typ）、加密算法（alg）
{
"alg": "HS256",
"typ": "JWT"
}
Claims ：包括需要傳遞的用戶信息
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
Signature： 根據(jù)alg算法與私有秘鑰進(jìn)行加密得到的簽名字串， 這一段是最重要的敏感信息，只能在服務(wù)端解密；
HMACSHA256(
base64UrlEncode(Headers) + "." +
base64UrlEncode(Claims),
SECREATE_KEY
)
編碼之后的JWT看起來是這樣的一串字符：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
nodejs+express+jwt-simple
auth.js
let jwt = require('jwt-simple');
let secret = "wangyy";
let time = 10;
module.exports = {
/*
*檢驗(yàn)token合法性
*/
validate:function(req,res,next){
let token = req.body.token||req.headers["xssToken"];
if(token){
let decodeToken = null;
try { //防止假冒token解析__
decodeToken = jwt.decode(token,secret,'HS256');
} catch (err) {
res.status(401).send("非法訪問"); return;
}
let exp = decodeToken.exp; if(!exp){
res.status(401).send("非法訪問");
}
let now = new Date().getTime();
if(exp>(now+time*60*1000)){
res.send({code:'002',"errorMsg":"授權(quán)超時(shí)"})
}
next();
}else{
res.status(401).send("非法訪問");
}
},
/* 生成token*/
makeToken(){
let Token = null;
let payload = {
time:new Date().getTime(),
exp:this.makeExp(time)
}
Token = jwt.encode(payload,secret,HS256) return Token;
},
/*生成token過期時(shí)間*/
makeExp:function(time){
let stam = time601000;
}
}
server.js
let express = require("express");
let app = express();
let bodyParser = require('body-parser');
let auth = require('./lib/auth.js');
let chalk = require('chalk'); app.use(bodyParser.json()); app.post('/login',function(req,res,next){
let Token = auth.makeToken();
res.json({result:"success",token:Token},200)
});
app.use('*',[auth.validate],function(req,res,next){
res.send('success');
});
app.listen('9999')
上面只是一個(gè)簡單的token生成和校驗(yàn)，如果有需要可以根據(jù)實(shí)際需要進(jìn)行邏輯處理
四.OAuth(開放授權(quán))
OAuth（開放授權(quán)）是一個(gè)開放標(biāo)準(zhǔn)，允許用戶授權(quán)第三方網(wǎng)站訪問他們存儲在另外的服務(wù)提供者上的信息，而不需要將用戶名和密碼提供給第三方網(wǎng)站或分享他們數(shù)據(jù)的所有內(nèi)容，為了保護(hù)用戶數(shù)據(jù)的安全和隱私，第三方網(wǎng)站訪問用戶數(shù)據(jù)前都需要顯式的向用戶征求授權(quán)。我們常見的提供OAuth認(rèn)證服務(wù)的廠商有支付寶，QQ,微信。
OAuth協(xié)議又有1.0和2.0兩個(gè)版本。相比較1.0版，2.0版整個(gè)授權(quán)驗(yàn)證流程更簡單更安全，也是目前最主要的用戶身份驗(yàn)證和授權(quán)方式。
下面是一張auth2.0的流程圖：
從圖中我們可以看出，auth2.0流程分為六布（我們就以csdn登陸為例）：
第一步. 向用戶請求授權(quán)，現(xiàn)在很多的網(wǎng)站在登陸的時(shí)候都有第三方登陸的入口，當(dāng)我們點(diǎn)擊等第三方入口時(shí)，第三方授權(quán)服務(wù)會引導(dǎo)我們進(jìn)入第三方登陸授權(quán)頁面。
通過第三方請求授權(quán)頁面的瀏覽器地址欄地址可以看出，
https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=https%3A%2F%2Fpassport.csdn.net%2Faccount%2Flogin%3Foauth_provider%3DQQProvider&state=test
這里的地址里面的%是瀏覽器強(qiáng)制編碼后的顯示我們可以使用decodeURIComponent進(jìn)行解碼，解碼后是這樣：
https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=100270989&redirect_uri=https://passport.csdn.net/account/login?oauth_provider=QQProvider&state=test
這個(gè)url地址我們可以看見Auth2.0常見的幾個(gè)參數(shù)：
response_type，返回類型
client_id，第三方應(yīng)用id,由授權(quán)服務(wù)器（qq）在第三方應(yīng)用提交時(shí)頒發(fā)給第三方應(yīng)用。
redirect_uri，登陸成功重定向頁面
oauth_provider，第三方授權(quán)提供方
state，由第三方應(yīng)用給出的隨機(jī)碼
第二步. 返回用戶憑證（code），并返回一個(gè)憑證（code），當(dāng)用戶點(diǎn)擊授權(quán)并登陸后，授權(quán)服務(wù)器將生成一個(gè)用戶憑證（code）。這個(gè)用戶憑證會附加在重定向的地址redirect_uri的后面
https://passport.csdn.net/account/login?code=9e3efa6cea739f9aaab2&state=XXX
第3步. 請求授權(quán)服務(wù)器授權(quán):
經(jīng)過第二部獲取code后后面的工作就可以交給后臺去處理的，和用戶的交互就結(jié)束了。接下來我的需要獲取Access Token，我們需要用他來向授權(quán)服務(wù)器獲取用戶信息等資源。
第三方應(yīng)用后臺通過第二步的憑證（code）向授權(quán)服務(wù)器請求Access Token，這時(shí)候需要以下幾個(gè)信息：
client_id 標(biāo)識第三方應(yīng)用的id，由授權(quán)服務(wù)器（Github）在第三方應(yīng)用提交時(shí)頒發(fā)給第三方應(yīng)用
client_secret 第三方應(yīng)用和授權(quán)服務(wù)器之間的安全憑證，由授權(quán)服務(wù)器（Github）在第三方應(yīng)用提交時(shí)頒發(fā)給第三方應(yīng)用
code 第一步中返回的用戶憑證redirect_uri 第一步生成用戶憑證后跳轉(zhuǎn)到第二步時(shí)的地址
state 由第三方應(yīng)用給出的隨機(jī)碼
第四步. 授權(quán)服務(wù)器同意授權(quán)后，返回一個(gè)資源訪問的憑證（Access Token）。
第五步. 第三方應(yīng)用通過第四步的憑證（Access Token）向資源服務(wù)器請求相關(guān)資源。
第六步. 資源服務(wù)器驗(yàn)證憑證（Access Token）通過
前后端常見的幾種鑒權(quán)方式(小結(jié))
第二種這個(gè)方式是利用服務(wù)器端的session(會話)和瀏覽器端的cookie來實(shí)現(xiàn)前后端的認(rèn)證,由于http請求時(shí)是無狀態(tài)的,服務(wù)器正常情況下是不知道當(dāng)前請求之前有沒有來過,這個(gè)時(shí)候我們?nèi)绻涗洜顟B(tài),就需要在服務(wù)器端創(chuàng)建一個(gè)會話(seesion),將同一個(gè)客戶端的請求都維護(hù)在各自得會會話中,每當(dāng)請求到達(dá)服務(wù)器端的時(shí)候,先去...
關(guān)于前后端鑒權(quán)的幾種方式
3、Token驗(yàn)證：Token作為令牌，通過在用戶登錄時(shí)生成，之后請求中攜帶Token進(jìn)行驗(yàn)證。與Session-Cookie機(jī)制相比，Token驗(yàn)證不存儲在服務(wù)器端，只通過比對Token的有效性來判斷請求是否合法，同時(shí)支持多種客戶端類型。此方法更為安全且廣泛應(yīng)用于現(xiàn)代系統(tǒng)。4、OAuth開放授權(quán)：用戶通過第三方平臺（如微信、QQ）授權(quán)...
【架構(gòu)師(第四十二篇)】服務(wù)端開發(fā)之常用的登錄鑒權(quán)方式
OAuth2第三方鑒權(quán) 使用cookie實(shí)現(xiàn)單點(diǎn)登錄簡單的，如果業(yè)務(wù)系統(tǒng)都在同一主域名下，比如wenku.baidu.com、tieba.baidu.com，就可以直接把cookiedomain設(shè)置為主域名baidu.com，百度也就是這么干的 SSO OAuth2SSO是OAuth2的實(shí)際案例，其他常見的還有微信登錄，github登錄等，當(dāng)涉及到第三方用戶登錄校驗(yàn)時(shí)，都會...
還分不清 Cookie、Session、Token、JWT?
JWT的使用方式有三種基本途徑：認(rèn)證、授權(quán)和狀態(tài)管理。在項(xiàng)目中使用JWT，通常需要處理JWT的生成、驗(yàn)證和過期等問題。Token與JWT的區(qū)別在于，JWT更側(cè)重于使用JSON格式進(jìn)行安全的數(shù)據(jù)傳遞。常見的前后端鑒權(quán)方式包括基于Token的鑒權(quán)和基于Session的鑒權(quán)。加密算法的選擇應(yīng)考慮安全性、性能和兼容性。分布式架構(gòu)下ses...
后臺系統(tǒng)的權(quán)限控制與管理
在查找資料并結(jié)合個(gè)人項(xiàng)目經(jīng)驗(yàn)后,我總結(jié)有以下有三種常見的方式。后端返回權(quán)限表或路由表 這種方式常見于管理員可以添加新角色,并且要給這個(gè)角色分配菜單。拿到的數(shù)據(jù)大概如下:{"data":{"id":1,"username":"admin","token":"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImlhdCI6MTY1MzM1NzIyNH0.1y-Ucq_MfF...
應(yīng)用鑒權(quán)
1.HTTP 是無狀態(tài)的，為了維持前后請求，需要前端存儲標(biāo)記 2.cookie 是一種完善的標(biāo)記方式，通過 HTTP 頭或 js 操作，有對應(yīng)的安全策略，是大多數(shù)狀態(tài)管理方案的基石 3.session 是一種狀態(tài)管理方案，前端通過 cookie 存儲 id，后端存儲數(shù)據(jù)，但后端要處理分布式問題 4.token 是另一種狀態(tài)管理...
Node如何實(shí)現(xiàn)jwt鑒權(quán)機(jī)制?說說你的思路
在Node.js中，JWT（JSON Web Token）是一種常用的身份驗(yàn)證機(jī)制。JWT由頭部（Header）、載荷（Payload）和簽名（Signature）三部分組成，用于在客戶端和服務(wù)器間安全傳輸信息。生成JWT時(shí)，通常借助`jsonwebtoken`庫，通過`sign`方法生成包含用戶id、name等信息的編碼字符串。客戶端將生成的token存儲在...
JWT-安全信息傳輸和用戶鑒權(quán)方法
JWT，即Json Web Token，是一種遵守RFC 7519標(biāo)準(zhǔn)的用于安全傳輸信息的方法，常見于用戶登錄場景，以替代傳統(tǒng)的cookie，用于保存用戶登錄狀態(tài)、過期時(shí)間等信息。JWT能夠提供安全性，因?yàn)樗趥鬏斶^程中進(jìn)行了數(shù)據(jù)簽名。在用戶登錄后，服務(wù)器生成JWT并將其發(fā)送給前端。前端在后續(xù)請求中攜帶JWT，后端據(jù)此判斷用戶...
當(dāng)后端給我返回了302狀態(tài)碼
這段代碼的核心是用戶鑒權(quán)。后端設(shè)想，當(dāng)前端發(fā)起接口請求，且用戶未登錄時(shí)，后端會響應(yīng)302狀態(tài)碼，以便前端無需處理直接跳轉(zhuǎn)到登錄頁面。然而，他們可能不知道，前端發(fā)起的Ajax請求并不能直接跳轉(zhuǎn)，甚至無法捕獲到302狀態(tài)碼。常見狀態(tài)碼 HTTP響應(yīng)狀態(tài)代碼指示特定HTTP請求是否已成功完成。響應(yīng)分為五類：信息...
網(wǎng)關(guān)系統(tǒng)就該這么設(shè)計(jì)(萬能通用),穩(wěn)的一批!
網(wǎng)關(guān)的通俗理解 想象一個(gè)辦公樓的入口，網(wǎng)關(guān)就像是這個(gè)入口的門衛(wèi)。所有訪客都需要通過這扇門進(jìn)入，門衛(wèi)負(fù)責(zé)驗(yàn)證訪客的身份和目的。門衛(wèi)會檢查訪客的證件（鑒權(quán)），判斷訪客的請求是否合理。如果請求不被允許，門衛(wèi)會拒絕訪客進(jìn)入。對于合理的請求，門衛(wèi)會提供指引（動態(tài)路由），比如告訴訪客去投資部找人，同時(shí)...
相關(guān)評說：
資中縣機(jī)構(gòu)： ______ a) 對客戶端做身份認(rèn)證 b) 對敏感的數(shù)據(jù)做加密,并且防止篡改 c) 身份認(rèn)證之后的授權(quán) 對客戶端做身份認(rèn)證,有幾種常見的做法: 在請求中加簽名參數(shù) 1.為每個(gè)接入方分配一個(gè)密鑰,并且規(guī)定一種簽名的計(jì)算方法.要求接入方的請求中必須加上簽名參...
資中縣機(jī)構(gòu)： ______ 內(nèi)鍋直徑22公分,整鍋直徑26公分左右,加上左右兩側(cè)的用于端提的耳朵有32公分左右.如果考慮到雙手要抓扶到鍋耳上,那么左右需要的立體空間尺寸約40公分,前后30公分足夠了.
資中縣機(jī)構(gòu)： ______ 所謂“異網(wǎng)漫游”就是與這家通信運(yùn)營商簽約的 SIM 卡也可以用另外一家通信運(yùn)營商的網(wǎng)絡(luò). 比如:國內(nèi)的 GSM 網(wǎng)絡(luò),移動和聯(lián)通之間,也是可以相互漫游的,在國外一部手機(jī)在運(yùn)營商之間進(jìn)行“異網(wǎng)漫游”是比較常見的做法.不過有一個(gè)前提是進(jìn)行“異網(wǎng)漫游”的運(yùn)營商雙方的 HLR 必須相互開放鑒權(quán),因?yàn)椴婚_放鑒權(quán)的話一個(gè)運(yùn)營商的手機(jī)是無法在另一個(gè)運(yùn)營商的 VLR 里完成注冊的,也就打不了電話.中國移動和中國聯(lián)通之間并沒有達(dá)成相互開放 HLR 的協(xié)議,也就無法進(jìn)行“異網(wǎng)漫游”.
資中縣機(jī)構(gòu)： ______ 顯示器花屏的一般原因及解決方法 顯示器花屏是極其常見的故障,產(chǎn)生的原因有多種,不同的原因所產(chǎn)生的故障現(xiàn)象也有所不同,解決方法也各異.在文本方式下的花屏表現(xiàn)為字符混亂,在圖形方式下通常表現(xiàn)為圖形分層,由于受到內(nèi)部或外部...
資中縣機(jī)構(gòu)： ______ 1. HTML賦值2. JS賦值3. script填充JSON4. AJAX獲取JSON5. WebSocket實(shí)時(shí)傳輸數(shù)據(jù)
資中縣機(jī)構(gòu)： ______ Session是服務(wù)器端的 內(nèi)存,如果每個(gè)交互之后Session都保留,那么服務(wù)器會吃不消的.如果需要保留一些統(tǒng)計(jì)信息的話,可以使用Application .但是,不建議用Application存登陸信息.要讓登陸信息在下次訪問時(shí)還可以使用,常見的方法是使用Cookie來存儲一些用戶數(shù)據(jù).這些數(shù)據(jù)在 Cookie過期之前都是可用的.
資中縣機(jī)構(gòu)： ______ 一、花木的象征意義 花木,千姿百態(tài),其色彩、風(fēng)韻不僅給人以美感,在人們心目中還有它特定的象征意義. 1、以松柏象征堅(jiān)貞.松枝傲骨崢嶸,柏樹莊重肅穆,且四季長青,歷嚴(yán)冬而不衰....
資中縣機(jī)構(gòu)： ______ 如果孩子在5歲時(shí),發(fā)音等還有問題,建議進(jìn)行舌系帶修整術(shù)
