W mojej aplikacji Grails dostosowałem przepływ pracy po autoryzacji, pisząc niestandardowy program obsługi autoryzacji (w zasobach.groovy), jak pokazano poniżej.

authenticationSuccessHandler (MyAuthSuccessHandler) {
    def conf = SpringSecurityUtils.securityConfig
    requestCache = ref('requestCache')
    defaultTargetUrl = conf.successHandler.defaultTargetUrl
    alwaysUseDefaultTargetUrl = conf.successHandler.alwaysUseDefault
    targetUrlParameter = conf.successHandler.targetUrlParameter
    useReferer = conf.successHandler.useReferer
    redirectStrategy = ref('redirectStrategy')
    superAdminUrl = "/admin/processSuperAdminLogin"
    adminUrl = "/admin/processAdminLogin"
    userUrl = "/admin/processUserLogin"
}

Jak możesz z ostatnich trzech wierszy w powyższym zamknięciu, w zależności od roli przyznanej do logowania Użytkownik przekierowuję ją do oddzielnych działań w ramachAdminController gdzie niestandardowa UserSessionBean jest tworzona i zapisywana w sesji.

Działa dobrze w przypadku zwykłego logowania, które w mojej aplikacji wygląda tak:

Użytkownik przychodzi do aplikacji za pośrednictwem jednegohttp://localhost:8080/my-app/ LUBhttp://localhost:8080/my-app/login/authWprowadza swój prawidłowy identyfikator logowania i hasło i kontynuuje.Aplikacja wewnętrznie uzyskuje dostęp do MyAuthSuccessHandler, który przekierowuje do AdminController, biorąc pod uwagę rolę przyznaną temu użytkownikowi.UserSessionBean jest tworzony i zapisywany w sesjiUżytkownik zostaje przeniesiony na stronę główną aplikacji

Napisałem również zwyczajMyUserDetailsService przedłużającGormUserDetailsService który jest poprawnie dostępny w powyższym przepływie.

SCENARIUSZ PROBLEMU:
Rozważmy, że użytkownik ma bezpośredni dostęp do chronionego zasobu (w tym przypadku kontroler jest zabezpieczony@Secured adnotacja) w aplikacji.

Kliknięcia użytkownikahttp://localhost:8080/my-app/inbox/indexAplikacja przekierowuje ją dohttp://localhost:8080/my-app/login/authUżytkownik wprowadza swój prawidłowy identyfikator logowania i hasłoUżytkownik zostaje przeniesiony dohttp://localhost:8080/my-app/inbox/index

TheMyAuthSuccessHandler jest całkowicie pomijany w tym procesie i stąd mójUserSessionBean nie jest tworzony, co prowadzi do błędów przy dalszym użyciu w miejscach, w którychUserSessionBean jest dostępny.

PYTANIA:

W scenariuszu problemu aplikacja pomijaMyAuthSuccessHandler ponieważ istnieje docelowy adres URL do przekierowania po zalogowaniu?Czy możemy zmusić proces, aby zawsze przechodziłMyAuthSuccessHandler nawet z docelowym adresem URL?Jeśli odpowiedź na 2 brzmi „nie”, czy istnieje alternatywa dla tego, jak i gdzieUserSessionBean nadal można utworzyć?