[jira] [Commented] (DELTASPIKE-749) Doc: Security: Making intitially requested and secured page available for redirect after login

["Gerhard Petracek (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DELTASPIKE-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193346#comment-14193346 ] 

Gerhard Petracek commented on DELTASPIKE-749:
---------------------------------------------

#1 without a scope for AuthenticationListener it's wrong, because it would be a dependent-scoped bean (dependent to a dyn. lookup in HandlerMethodImpl).
#2 it depends where you are using your access-decision-voter (if it's only in the ui-module, you can do it directly without breaking layering)
#3 with a view-specific exception handler you just move the issue to the next point in the chain
#4 you can just decouple it with a LoggedInFailedEvent -> one session-/window-scoped observer bean would need to observe both LoggedInFailedEvent as well as LoggedInEvent
#5 we can document both - the simple case (which is sometimes just enough - see #2) as well as a more layered case

> Doc: Security: Making intitially requested and secured page available for redirect after login
> ----------------------------------------------------------------------------------------------
>
>                 Key: DELTASPIKE-749
>                 URL: https://issues.apache.org/jira/browse/DELTASPIKE-749
>             Project: DeltaSpike
>          Issue Type: Bug
>          Components: Documentation
>            Reporter: Ron Smeral
>            Priority: Minor
>
> http://deltaspike.apache.org/documentation/security.html#_making_intitially_requested_and_secured_page_available_for_redirect_after_login
> In _CDI Implementation to redirect the login to the first denied page_:
> * change Usuario to User
> * why use {{char[]}} for password? Is that some security measure, to prevent interned Strings of passwords hanging around in memory? If so, that should be noted, otherwise it should be changed to String, it's confusing. 
> In CDI and PL implementations: 
> * -the AdminAccessDecisionVoter should implement AccessDecisionVoter, not extend AbstractAccessDecisionVoter-
> * I think the {{AdminAccessDecisionVoter}} should be agnostic of the view layer and therefore shouldn't inject {{ViewConfigResolver}} and shouldn't keep the denied page itself.
> Maybe the listener could handle the {{AccessDeniedException}} instead:
> Basic voter:
> {code:java|title=AdminAccessDecisionVoter.java}
> @SessionScoped //or @WindowScoped
> public class AdminAccessDecisionVoter extends AbstractAccessDecisionVoter {
>     @Override
>     protected void checkPermission(AccessDecisionVoterContext context, Set<SecurityViolation> violations) {
>         // voting stuff
>     }
> }
> {code}
> The listener/holder/handler:
> {code:java|title=AuthenticationListener.java}
> @ExceptionHandler
> public class AuthenticationListener {
>     @Inject ViewNavigationHandler viewNavigationHandler;
>     @Inject ViewConfigResolver viewConfigResolver;
>     private Class<? extends ViewConfig> deniedPage;
>     public void rememberDeniedView(@BeforeHandles ExceptionEvent<ErrorViewAwareAccessDeniedException> evt) {
>         deniedPage = viewConfigResolver.getViewConfigDescriptor(FacesContext.getCurrentInstance().getViewRoot().getViewId()).getConfigClass();
>         evt.handledAndContinue();
>     }
>     public void handleLoggedIn(@Observes UserLoggedInEvent event) {
>         if(deniedPage != null) {
>             viewNavigationHandler.navigateTo(deniedPage);
>             deniedPage = null;
>         }
>         viewNavigationHandler.navigateTo(Pages.Home.class);
>     }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)