的require_previous_session
設置有點斜,但可以(希望)與一些代碼來解釋。
所以ordinarilly,當你建立了一個標準的形式登錄(如the docs),在你的security.yml文件設置您的防火牆具有圖案(比如/user
),並設置anonymous
選項。現在,在您訪問控制下來,你設定的登錄頁面(比如/user/login
)擁有的IS_AUTHENTICATED_ANONYMOUSLY
的作用,就像這樣:
firewalls:
default:
pattern: ^/user
anonymous: ~
form_login:
login_path: /user/login
check_path: /user/login_check
access_control:
- { path: ^/user/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/user, roles: ROLE_USER }
現在,當有人去/user
是他們獲得轉發到/user/login
會發生什麼; 但他們這樣做時,他們將爲他們創建一個會話(如果他們還沒有創建)並且他們的分配角色將是anon
(您可以在/user/login
上的Symfony工具欄中進行檢查),如上面的access_control
部分所允許的。
這意味着無論何時有人登錄(即將憑據發送至/user/login_check
),他們將已經爲他們創建會話,而require_previous_session
將爲true。
對於大多數人來說,這很好,你不必擔心這個設置。但是,如果您開始觸摸安全組件的邊緣,例如創建自己的身份驗證提供程序或禁用安全性(特定模式的security: false
,請參閱默認的dev
防火牆以查看相關示例),那麼您可能會遇到這種情況問題。
據我所知,在登錄之前沒有會話沒有安全處罰 - 我有生產站點在這種情況下進行。但是,您可以在登錄表單上使用CSRF令牌(cookbook entry)以獲得額外的安全性,這意味着對用戶帳戶的攻擊要困難得多。
短版本:如果解決了您的問題,我不擔心設置該選項。根據您的網站規模,這樣做可能會帶來性能上的提升(如果您可以登錄整個網站,但未經身份驗證的用戶不需要會話),但是安全方面,您應該很好。
編輯,例如從上面require_previous_session
設置爲false:
firewalls:
default:
pattern: ^/user
anonymous: ~
form_login:
login_path: /user/login
check_path: /user/login_check
require_previous_session: false
難道您發佈security.yml文件,看你怎麼配置呢? – angelwally