2013-02-26 48 views
3

我的問候。春季安全從相同的IP地址登錄幾個

我有這樣的問題。春季安全有沒有辦法檢查來自同一個IP地址的登錄數量?我的意思是,如果有人從當前IP登錄,我想告訴他他不能使用不同的憑據(例如來自不同的瀏覽器)登錄並拒絕登錄嘗試。

我想谷歌一下,發現以下,但它不是我在尋找的東西:

IP filter using Spring Security

Authenticating By IP Address In Spring 3.1: Smartest Way To Do That?

+2

呃,這是一個棘手的事情要做。如果您的應用程序是公開的,那意味着網絡中的人可能無法登錄到您的應用程序。例如幾乎任何在公司網絡中工作的人,甚至是咖啡店裏的人,因爲他們會共享相同的IP。我要求你回覆的是:你確定要拒絕來自同一IP的人登錄嗎?在我工作之前的一些地方,我們從同一個IP獲得了500次唯一登錄。 – Augusto 2013-02-26 15:37:28

+0

是的,我也考慮過這個問題,但是,如果我知道數量,我可以設置一個限制,所以不會有來自同一IP的「超過9000次」登錄嘗試。我可以在來自同一個IP的100次登錄中放置阻止程序並創建某種通知。 – user 2013-02-26 15:39:23

回答

3

一個可能的解決方案是實現一對自定義AuthenticationSuccessHandlerLogoutSuccessHandler(都可以訪問http請求)可以維護一個併發映射,其中保持由其ip地址鍵入的登錄用戶數。然後添加一個自定義過濾器,攔截登錄請求,檢查映射,並重定向用戶,如果從他的IP地址的用戶數量超出限制。

1

我覺得沒有辦法做到這一點了的盒子。您可以做的實際上是限制一個瀏覽器實例的最大連接數量(請參閱concurrent session chapiter)。

如果這對於您來說還不夠,那麼您可以手動完成(感謝Spring Security中精心設計的擴展點)。按照解釋here定義您的自定義過濾器。聲明會話註冊表的別名和load all principals。在正常情況下,每個主體將由認證對象表示。 Authentication.getDetails()可能包含一個IP地址。查找重複項並將用戶重定向到某個錯誤頁面。希望這可以幫助。

編輯。這不起作用,因爲會話註冊中心的主體實際上是org.springframework.security.core.userdetails.User的實例,而不是Authentication。

+0

我很害怕這樣做不行,因爲'SessionRegistry'中的主體不是'Authentication'對象,而是'UserDetails'的實例。人們可以通過創建一個'AuthenticationProvider'來創建一個主體,該主體可以引用Authentication.getDetails()返回的內容,但是如果某人從不同的IP用同一個用戶登錄會怎麼樣呢?他不會被計入他用於第一次登錄的IP。 – zagyi 2013-02-27 13:39:37

+0

@zagyi感謝您指出這一點 – 2013-02-27 15:02:09

0

SessionAuthenticationStrategy是監視和控制登錄嘗試的關鍵。已有ConcurrentSessionControlStrategy限制會話使用相同的用戶名登錄。你可以擴展它或從中學習。並重定向或轉發到錯誤頁面SimpleUrlAuthenticationFailureHandler

/** 
* Strategy which handles concurrent session-control, in addition to the functionality provided by the base class. 
* 
* When invoked following an authentication, it will check whether the user in question should be allowed to proceed, 
* by comparing the number of sessions they already have active with the configured <tt>maximumSessions</tt> value. 
* The {@link SessionRegistry} is used as the source of data on authenticated users and session data. 
* <p> 
* If a user has reached the maximum number of permitted sessions, the behaviour depends on the 
* <tt>exceptionIfMaxExceeded</tt> property. The default behaviour is to expired the least recently used session, which 
* will be invalidated by the {@link ConcurrentSessionFilter} if accessed again. If <tt>exceptionIfMaxExceeded</tt> is 
* set to <tt>true</tt>, however, the user will be prevented from starting a new authenticated session. 
* <p> 
* This strategy can be injected into both the {@link SessionManagementFilter} and instances of 
* {@link AbstractAuthenticationProcessingFilter} (typically {@link UsernamePasswordAuthenticationFilter}). 
* 
* @author Luke Taylor 
* @since 3.0 
*/ 
public class ConcurrentSessionControlStrategy extends SessionFixationProtectionStrategy