自定義過濾器和shiro攔截沖突

Ⅰ shiro驗證成功後 重定向到 /undefined，怎麼解決

多種情況會導致【循環重定向】即302報錯。你提到了shiro，在shiro最常見的情況是過濾器循環觸發，檢查思路：

通過瀏覽器debug， 找到循環訪問了哪個請求【狀態為302】， 根據這個請求url，修改shiro配置文件中:
bean名為[org.apache.shiro.spring.web.ShiroFilterFactoryBean]中
property名為[filterChainDefinitions]中的[value]對應的過濾值
當然也有可能是其他filter、controller類中的代碼反復觸發了這個url。

Ⅱ Shiro中的filter

DefaultFilter

shiro中提供的默認filter

FilterChainManager

通過配置創建對應的filterChain

Shiro通過此配置可初始化FilterChainManager中的filterChain，結構為 url ->filter列表

SpringShiroFilter

入口filter，攔截所有請求，通過請求的url匹配到對應的filterChain，然後通過Chain對請求進行，認證或者授權的處理

OncePerRequestFilter

OncePerRequestFilter 用於防止多次執行 Filter；也就是說一次請求只會走一次攔截器鏈；

另外提供 enabled 屬性，表示是否開啟該攔截器實例

實現了 doFilter 方法，提供了抽象方法 doFilterInternal 。

在doFilter中驗證當前的Filter有沒有執行過，如果已經執行過一次或者當前filter被禁用，則直接執行下一個Filter。如果沒有執行過則執行 doFilterInternal 方法

AbstractShiroFilter

創建Subject,綁定subject到當前線程，根據url獲取filterChain並執行filterChain

通過請求的url來匹配FilterChainManager中的FilterChain，這個方法會返回一個 ProxiedFilterChain

ProxiedFilterChain

存儲了tomcat的Filter 和shiro內部的filter

shiro內部的過濾器執行完後會切換到tomcat的過濾器繼續執行

默認filter

除了LogoutFilter，其他都繼承了AdviceFilter

AdviceFilter

AdviceFilter 提供了 AOP 風格的支持，類似於 SpringMVC 中的 Interceptor：

許可權驗證在preHandle中實現

PathMatchingFilter

PathMatchingFilter 提供了基於 Ant 風格的請求路徑匹配功能及攔截器參數解析的功能，如

「 /admin roles[admin,user] 」自動根據 「，」 分割，解析成 /admin -> [admin,user] 存入 appliedPaths 中

實現了 preHandle 方法，通過請求的url匹配url對應的許可權，解析許可權串 調用子類的 onPreHandle 對許可權進行處理

AnonymousFilter

提供匿名訪問功能，實現了 onPreHandle 直接返回true，所以配置 anon 的url任何人都可以訪問

AccessControlFilter

提供了資源訪問控制的基礎功能

實現了 onPreHandle ，這里拆分出了

isAccessAllowed （是否允許訪問）和 onAccessDenied （訪問被拒絕時）這兩個方法供子類實現

AuthenticationFilter

實現了 isAccessAllowed 方法，驗證用戶是否已經登錄，沒有登錄將被拒絕

FormAuthenticationFilter

繼承自 AuthenticationFilter 只有用戶登錄過後才能通過

實現了 onAccessDenied 方法，如果請求的地址是登錄地址，這里會嘗試自動登錄，否則跳轉到登錄頁面

BasicHttpAuthenticationFilter

提供了基於 HttpBasic認證的方式

AuthorizationFilter

實現了 onAccessDenied 方法，如果沒有認證通過，則跳轉到登錄或者認證失敗的頁面

對用戶所訪問資源的許可權進行認證

HttpMethodPermissionFilter

將HTTP請求的方法(例如GET、POST等)轉換為相應的動作並構造一個相應的許可權

如get 被轉換為 read，put 轉換為 update，post轉換為create等

許可權配置：/users perms[users]

請求： get /users

將會驗證 用戶是否擁有users:read許可權

RolesAuthorizationFilter

驗證用戶是否用對對應的角色

UserFilter

實現了 isAccessAllowed 和 onAccessDenied 方法，驗證用戶是否登錄過，如果驗證未通過則跳轉到登錄頁面

Ⅲ shiro過濾器/* = authc把自己寫的都攔截了,走了上面的攔截器後還是會被/*攔截

我也碰到這種情來況了，，自，發現filters.put("authc", filter_Authc());這種方式注入filter的時候，攔截順序會失效，，，要改成new xx()這種方式才可以filters.put("authc", new Filter_Authc());

Ⅳ springMvc+shiro做許可權管理，頁面上的靜態資源，樣式圖片等沒有出現，用幾種方式過濾試過，還是不行

正常情況是不會出現這樣的，shiro對於靜態資源的處理，不用特殊配置。

只需要在shiroFilter過濾器filterChainDefinitions項中增加一個靜態資源處理規則就可以，例如允許/css/開頭的資源匿名訪問，只需要這樣一句配置就足矣。

/css/** = anon

配置完成後，未登錄就可以在瀏覽器中直接訪問css下的資源，新項目用的shiro，簡單而又實用的許可權框架。

Ⅳ spring mvc攔截器與shiro攔截器有什麼區別

奉獻，分享他們的經驗與心得，才能讓像我這樣的小白有機會站一下你們這些巨人的肩膀，才能少走些彎路）。

過濾器和攔截器的區別：
①攔截器是基於java的反射機制的，而過濾器是基於函數回調。
②攔截器不依賴與servlet容器，過濾器依賴與servlet容器。
③攔截器只能對action請求起作用，而過濾器則可以對幾乎所有的請求起作用。
④攔截器可以訪問action上下文、值棧里的對象，而過濾器不能訪問。
⑤在action的生命周期中，攔截器可以多次被調用，而過濾器只能在容器初始化時被調用一次。
⑥攔截器可以獲取IOC容器中的各個bean，而過濾器就不行，這點很重要，在攔截器里注入一個service，可以調用業務邏輯。

Ⅵ shiro原理之過濾器

這幾天一直在研究Shiro到底是如何工作的，即一個請求過來了，它是如何做到知道這個請求應該用什麼方式來鑒權的？應該調用哪個過濾器？自己定義的過濾器該如何才能生效？

帶著這樣的疑問，我做了一些測試與研究，並記錄於此文。

Shiro對於請求的鑒權的實現也是通過過濾器（或者說是攔截器）來實現的，但是Spring項目中有攔截鏈機制，會有多個攔截器生效，包括系統內置的以及Shiro注入的，所以需要搞懂他的過濾的實現機制就需要去弄明白這些過濾器是如何過濾的。

在 ApplicationFilterChain 的 doFilter 方法下打上斷點

默認過濾器

我們來看看 AbstractShiroFilter 的部分源碼：

返回的是一個 ProxiedFilterChain 的實例，該實例包含了 所匹配出來的過濾器，如下圖，匹配的是系統內置的名為 anon 過濾器，至於它所對應的過濾器是什麼可以見上面默認過濾器的表。

接著，在 AbstractShiroFilter 中的 executeChain 就會執行它的 doFilter 方法。

剛開始學習看源碼，IDEA的調試工具也不是很會用，好在確實IDEA很強大，不然這么多過濾鏈跳來跳去是真的難懂。經過這次的閱讀以及網上的博客的研究，Shiro的過濾鏈如果有自定義的過濾鏈的話，一定不能像平常的攔截器那樣注入，必須要在注入 ShiroFilterFactoryBean 時使用如下方式注入才能生效。

因為很可能像平常注入過濾器那樣注入先後順序可能會存在問題。

Ⅶ Shiro入門之攔截器機制

  Shiro使用了與Servlet一樣的Filter介面進行擴展，下圖是 Shiro 攔截器的基礎類圖：

  （1） NameableFilter：該攔截器的作用就是給 Filter 起一個名字，如果沒有設置默認就是 FilterNmae.比如在 shiro.ini文件中[main]中的配置： authc.loginUrl=/login ，其中 authc 就是攔截器名稱，當我們組裝攔截器鏈時，會根據這個名稱找到相應的攔截器實例。
  （2）OncePerRequestFilter：用來防止對此執行 Filter，也就是一次請求最多隻會經過該過濾器一次，另外提供 enabled 屬性，表示是否開啟該攔截器實例，默認 enabled=true 表示開啟，如果不想讓某個攔截器工作，可以設置為 false 即可。
  （3） ShiroFilter：是整個 Shiro的入口點，用於攔截需要安全控制的請求。
  （4）AdviceFilter：類似於 Spring中的AOP。
  （5）PathMatchingFilter：提供了用於Ant 風格的請求路徑匹配功能及攔截器參數解析的功能，如 「roles[admin,user]」自動根據「，」分割解析到一個路徑參數配置並綁定到相應的路徑（路徑和對應所需要的許可權）。
  （6）AccessControlFilter：該過濾器提供了訪問控制的基礎功能，比如是否允許訪問，訪問拒絕之後如何處理等。
  如果我們想進行訪問的控制就可以繼承AccessControlFilter；如果我們要添加一些通用數據我們可以直接繼承 PathMatchingFilter。
  Shiro 對 Servlet 容器的 FilterChain 進行了代理，即 ShiroFilter 在繼續Servlet容器的Filter鏈的執行之前，通過 ProxiedFilterChain 對Servlet 容器的 FilterChain 進行了代理；即先走Shiro 自己的Filter體系，然後才會委託給 Servlet 容器的 FilterChain 進行 Servlet 容器級別 的 Filter 鏈執行；Shiro ProxiedFilterChain 執行流程：先執行 Shiro 自己的 Filter 鏈； 再執行 Servlet 容器的 Filter 鏈（即原始的 Filter）。
   ProxiedFilterChain 是通過 FilterChainResolver 對 shiro.ini文件[urls]中的配置獲取每個路徑對應的攔截器鏈的。Shiro提供了一個 FilterChainResolver 的默認實現類 ，而 內部通過 FilterChainManager 維護攔截器鏈，比如 DefaultFilterChainManager 實現維護著 url 模式與攔截器鏈的關系。因此我們可以通過獲取 FilterChainManager 實例進行動態動態增加 url 模式與攔截器鏈的關系。
  DefaultFilterChainManager類會默認添加枚舉類DefaultFilter中定義的攔截器。
  如果要注冊自定義攔截器， IniSecurityManagerFactory / WebIniSecurityManagerFactory 在啟動時會自動掃描 ini 配置文件中的 [filters]/[main] 部分並注冊這些攔截器到 DefaultFilterChainManager中，且創建相應的 url 模式與其攔截器關系鏈。
  如果想要自定義攔截器鏈解析器 FilterChainResolver ，需要實現 WebEnvironment 介面。

  Shiro 內置了很多默認的攔截器，比如身份驗證、授權等相關的。默認攔截器可以參考org.apache.shiro.web.filter.mgt.DefaultFilter 中的枚舉攔截器：

  這些默認的攔截器可以注冊，可以在 ini 文件中設置這些攔截器的屬性，比如:

  自定義攔截器案例
  （1）自定義攔截器

  （2） shiro.ini中的配置

Ⅷ 怎麼自定義shiro中的過濾器來允許ajax請求後台數據

自定義過濾器：

public class extends FormAuthenticationFilter {

@Override
protected boolean onAccessDenied(ServletRequest request, ServletResponse response) throws Exception {
if (isLoginRequest(request, response)) {
if (isLoginSubmission(request, response)) {
return executeLogin(request, response);
} else {
// 放行 allow them to see the login page ;)
return true;
}
} else {
HttpServletRequest httpRequest = WebUtils.toHttp(request);

if (ShiroFilterUtils.isAjax(httpRequest)) {

HttpServletResponse httpServletResponse = WebUtils.toHttp(response);
httpServletResponse.sendError(ShiroFilterUtils.HTTP_STATUS_SESSION_EXPIRE);

return false;

} else {
saveRequestAndRedirectToLogin(request, response);
}

return false;
}
}

/**
* 判斷ajax請求
* @param request
* @return
*/
boolean isAjax(HttpServletRequest request){
return (request.getHeader("X-Requested-With") != null && "XMLHttpRequest".equals( request.getHeader("X-Requested-With").toString()) ) ;
}

}

封裝ajax

var Error = function () {

return {
// 初始化各個函數及對象
init: function () {

},

// 顯示或者記錄錯誤
displayError: function(response, ajaxOptions, thrownError) {
if (response.status == 404) {// 頁面沒有找到
pageContent.load($("#hdnContextPath").val() + "/page/404.action");
} else if (response.status == 401) {// session過期
SweetAlert.errorSessionExpire();
} else if (response.status == 507) {// 用戶訪問次數太頻繁
SweetAlert.error("您的訪問次數太頻繁, 請過一會再試...");
} else {//其他錯誤
window.location = $("#hdnContextPath").val() + "/page/500.action";
}
console.log(thrownError);
}

};

}();

jQuery(document).ready(function() {
Error.init();
});

JS的引用處如下：

App.blockUI();

$.ajax({
url: $("#hdnContextPath").val() + "/feedback/queryFeedBackDetail.action",
type: "POST",
async: false,
data: {"feedbackId": feedbackId, "userId": userId, "status": status},
success: function(data) {
// 忽略

Ⅸ 怎麼不讓shiro攔截所有請求

#全部不用攔截
/**=anon
推薦一套完整的Shiro Demo，免費的。
Shiro介紹文檔：http://www.sojson.com/shiro
Demo已經部署到線上，ShiroDemo:http://shiro.itboy.net
管理員帳號：admin，密碼：sojson.com 如果密碼錯誤，請用sojson。PS：你可以注冊自己的帳號，然後用管理員賦許可權給你自己的帳號，但是，每20分鍾會把數據初始化一次。建議自己下載源碼，讓Demo跑起來，然後跑的更快。

Ⅹ Spring Security自定義攔截器

HttpSecurity實際上就是在配置Spring security的過濾器鏈，比如：CSRF，CORS，表單登錄等，每個配置器對應一個過濾器，可以通過HttpSecurity配置過濾器的行為。

甚至可以像CRSF一樣直接關閉過濾器，例如：SessionManagement

Spring Security通過SessionManagermentConfigurer來配置SessionManagerment的行為，與SessionManagermentConfigurer類似的配置器還有CorsConfigurer，RememberMeConfigurer等，他們都實現了SecurityConfigurer的標准介面。

SessionManagementConfigurer是在configure方法中將最終的SessionManagementFilter插入過濾器鏈來實現會話管理的。

除了Spring security提供的過濾器外，我們還可以添加自己的過濾器以實現更多的功能，這些都是可以在HttpSecurity中實現

雖然Spring Security 的過濾器鏈對過濾器沒有特殊要求，只要繼承了Filter即可，但是在Spring體系中，推薦使用OnePerRequestFilter來實現，它可以確保一次請求只會通過一次該過濾器（Filter實際並不能保證這一點）

其實關於這個自定義Filter，我個人感覺有個比較danteng的地方，比如：我們在實現圖片驗證碼或者一些其他的登錄相關的驗證碼的時候，我們可能會做到在賬號跟密碼驗證了之後對這個驗證碼進行驗證，然後我就必須有個這種操作: http.addFilterBefore(filter,.class); 因為如果驗證碼驗證錯誤，我們就不需要也沒必要再往後驗證了，所以我們得知道我們定義的這個驗證碼過濾器得在什麼時候驗證在哪個過濾器之前或者之後驗證，那麼問題來了，或許我們並不知道Spring Security給我們提供了哪些或者什麼樣的過濾器，我們得去記住這些過濾器，這就有點不友好了。在HttpSecurityBuilder介面中，有一段這樣的注釋:

非常爽眼~