之前的專案已經上線了，對於客戶有點數控制要求，因此要接入公司的授權服務，進行客戶端登入點數的控制。
公司的授權服務主要是針對客戶端應用程式的，針對web應用程式的授權控制需要在伺服器端進行操作，與客戶端的控制還是有一些區別的。
web端使用的使用者識別符號
不同於單機的exe產品，可以方便地讀取pc的硬體資訊，然後使用硬體標識作為使用者的唯一標識，以確定該使用者（或者該pc）占用了乙個點數。
對於web端產品來講，js無法方便地讀取硬體資訊（好像僅有ie可以通過activex外掛程式來進行讀取），所以需要考慮乙個替代方案。
此時就想到了利用cookie：
- 使用者登入到伺服器的時候，隨機生成乙個uuid作為該使用者的識別符號；
- 將該uuid寫入到使用者的瀏覽器cookie中；
- 之後的每次請求以及心跳都攜帶該cookie資訊上傳到伺服器，就可以標識該使用者了；
這樣做會有乙個弊端：
同乙個使用者在同一臺電腦上使用多個瀏覽器的時候，該使用者將占用多個點數。不過這樣也是合理的。
應用伺服器與授權伺服器互動的加密秘鑰
應用伺服器與授權伺服器之間的互動需要進行加密處理。
採用的加密演算法是aes對稱加密，即加密/解密的秘鑰是一致的。而這個秘鑰並沒有提前約定，而是每次通訊的時候臨時約定（也就是秘鑰資訊會包含在請求中）。
由於應用伺服器與授權伺服器之間的通訊是由應用伺服器主動請求，授權伺服器被動響應的，即典型的請求/響應模式。所以對於一次請求/響應，應用伺服器需要記住秘鑰，而授權伺服器可以用完就扔。
而出於安全考慮，秘鑰確定採用了乙個小技巧：
- 授權伺服器提前生成乙個uuid，執行md5處理後將該uuid的前16位擷取出來，與應用伺服器提前約定好作為秘鑰的前16位；
- 應用伺服器每次請求的時候，隨機生成乙個uuid並做md5處理後，作為請求引數的一部分傳送請求；
- 而雙方實際使用的秘鑰是提前約定的uuid&md5的前16位，加每次隨機生成的uuid&md5的前16位；
這樣也保證了傳輸過程中的秘鑰安全性，也保證了每次加解密秘鑰的隨機性。
加解密&cipher使用
private
static string encrypt(string key, string content) catch (nosuchalgorithmexception e) catch (invalidkeyexception e) catch (nosuchpaddingexception e) catch (badpaddingexception e) catch (illegalblocksizeexception e)
return
""; }
private
static string decrypt(string key, string content) catch (nosuchalgorithmexception e) catch (invalidkeyexception e) catch (nosuchpaddingexception e) catch (badpaddingexception e) catch (illegalblocksizeexception e)
return
""; }
private
static
final
char hexdigits = ;
private
static string md5(string info) catch (nosuchalgorithmexception e)
digest.update(info.getbytes());
byte infobytes = digest.digest();
char infochars = new
char[infobytes.length * 2];
int k = 0;
for (byte b : infobytes)
return
new string(infochars);
}
伺服器互動是使用httpclient的post方法進行互動的。
引數傳遞直接傳遞加密字串，而不是鍵值對。也就是說httppost的setentity引數傳遞的是string，而不是list。
okay，如上！
LocalDNS 授權伺服器
1 dns 網域名稱系統。2 localdns 提供快取和遞迴的服務。3 授權dns 提供權威解析。4 原始問題 使用者傳送的dns請求所查詢的問題。5 派生問題 在進行遞迴查詢的過程中會不斷派生新問題，稱之為派生問題。6 活動派生問題 在遞迴的整個過程中已向授權伺服器發出請求，還未收到響應的派生問...
IDEA 搭建授權伺服器
引用位址 今天突出發現基本公開的啟用位址都被遮蔽了 idea 2017.3 版本 記錄一下 docker pull ilanyu golang reverseproxy docker run d p 8888 8888 ilanyu golang reverseproxy 使用 ip 8888 埠 ...
Linux web伺服器分割槽方案
看到大家非常關心linux下web 伺服器的分割槽方案,很久沒有寫原創文章了,今天也加班貢獻一次,下邊是正文 linux伺服器的最大應用領域在web伺服器,很多朋友在第一次安裝linux伺服器時最先想到的就是如何分割槽,乙個合理的分割槽可以省去您許多的麻煩,尤其是在個人伺服器很少新增硬體的情況下,最...