如何對資源(前端頁面+后端接口)進行權限控制
在微服務架構中,請求的攔截在gateway中完成,而權限的查詢是在uaa中完成,在gateway和uaa集成部署的情況下實現較為簡單,如果兩者分離實現起來就會比較麻煩,一種方案是在gateway的資源filter中內部調用uaa的權限查詢模塊,該方案是可行的,但是存在兩個弊端:
響應延時:每個資源的請求都會附帶一次uaa內部調用,加重uaa服務的負擔并延長了響應時間。
過度依賴:gateway作為api網關,過度依賴了api提供方(uaa)的內部方法,導致系統耦合度提升。
因此應尋找一種低響應延時、松散依賴的解決方案:“token擴展”。
"token擴展"的思路為在token形成時追加用戶資源權限(ar)屬性,在資源的攔截中獲取ar并與當前請求的資源比對,相當于將用戶的資源權限緩存到了token中,uaa通過客戶端瀏覽器將權限信息傳遞至gateway,gateway直接解析request獲取AR,避免了內部調用導致的過度依賴問題和相應延時問題。此方案應注意在用戶登錄期間的AR變動需在下次登錄后方能生效?。?!
具體步驟如下:
uaa中擴展token屬性(具體步驟參考最后部分),如在token中擴展ar屬性,內部包含當前用戶有權限訪問的前端頁面列表
{...,"ar":["a.html","b.html"]}
gateway中攔截鑒權
//解析ar Cookie accessTokenCookie = OAuth2CookieHelper.getAccessTokenCookie(request); Maptoken 屬性擴展additionalInformation = tokenStore.readAccessToken(accessTokenCookie.getValue()) .getAdditionalInformation(); List ar = (List ) additionalInformation.get("ar"); //鑒權 for (String resourceUrl : ar) { if (resourceUrl == null) { continue; } if (resourceUrl.startsWith(requestUri)) { return false; } }
org.springframework.security.oauth2.provider.token.TokenEnhancer#enhance提供了擴展token屬性的可能性,以下demo在token中增加ar屬性,并使用@Component注入容器以生效。
@Component public class ArTokenEnhancer implements TokenEnhancer { @Override public OAuth2AccessToken enhance(OAuth2AccessToken accessToken, OAuth2Authentication authentication) { addClaims((DefaultOAuth2AccessToken) accessToken,authentication); return accessToken; } private void addClaims(DefaultOAuth2AccessToken token, OAuth2Authentication authentication) { MapadditionalInformation = token.getAdditionalInformation(); additionalInformation.put("ar", "something you like"); token.setAdditionalInformation(additionalInformation); } }
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/72705.html
摘要:口服務的負載均衡。服務的注冊與發現接口管理服務注冊是指向服務注冊中心注冊一個服務實例,服務提供者將自己的服務信息如服務名地址等告知服務注冊中心。服務注冊中心會提供服務的健康檢查方案,檢查被注冊的服務是否可用。服務降級的功能。 微服務具有以下的特點。 口 按照業務來劃分服務,單個服務代碼量小,業務單一,易于維護。 口 每個微服務都有自己獨立的基礎組件,例如數據庫、 緩存等,且運行在獨立...
摘要:參與者流量來自于內部系統和外部流量,其中大部分來自于外部流量。水平擴容服務的水平擴容重要性不言而喻。 背景 目前微店中臺團隊為了滿足公司大部分產品、運營以及部分后端開發人員的嘗鮮和試錯的需求,提供了一套基于圖形化搭建的服務端接口交付方案,利用該方案及提供的系統可生成一副包含運行時環境定義可立即運行的工程代碼,最后,通過 某種serverless平臺 實現生成后代碼的部署、CI、運行、反...
摘要:協議轉換微服務架構允許使用不同的協議以便于獲得使用不同技術的優勢。過于龐大的在實現時,應當避免將非通用邏輯如領域特定數據轉換放入其中。服務應始終對其數據域擁有完全的所有權。構建一個過于龐大的,從服務團隊爭奪控制權,這違反了微服務的理念。 我們團隊的后端服務中,一開始只有一個大服務,所有的東西都往里面寫,可以想象下,當這個服務變得不斷的龐大,將會變得多么難以維護。后來逐漸把一些數據服務抽...
摘要:本文主要是從前端的角度,使用搭建一個簡易的測試項目,在自己搭建的代理服務的下實現簡單的微信分享。在微信測試工具中調試接口,點擊發送即可會出現比較漂亮的分享鏈接。 一、背景簡介: 目前流行的前后端分離項目,一般都處于不同的域名下,前后端開發過程中,是分別部署在不同服 務器上,在做接口聯調時,會出現跨域的情況,部署上線時,基本不存在這種需要,因此搭建一個 前端代理服務,方便開發。 作為一個...
閱讀 2907·2021-11-15 18:02
閱讀 3801·2021-10-14 09:43
閱讀 3733·2021-09-08 10:41
閱讀 2522·2019-08-30 15:53
閱讀 1804·2019-08-30 14:14
閱讀 1943·2019-08-29 16:12
閱讀 3139·2019-08-29 14:03
閱讀 1280·2019-08-29 13:46