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

Ron Smeral commented on DELTASPIKE-749:
---------------------------------------

Thanks for clarification on the exception-handler-observer problem, I haven't 
realised it could be an issue. I guess DS should try to follow expectations of 
users as much as possible in these cases. Especially when it comes to adding 
behaviours/aspects by annotations -- that's something every EE developer will 
expect from an EE extension/framework, since all EE is based around this notion 
(as shown e.g. in http://java.dzone.com/articles/monster-component-java-ee-7).

So, based on this discussion, I'll make a PR for a generic CDI version of the 
code, incorporating your comments, and possibly the PL version as well. 

I also had the idea, that maybe it would be best to have such longer examples 
in a separate part of documentation, something like "Solutions" (anything 
longer than a snippet, but less than a quickstart/example). IMHO, these long 
code blocks clutter the documentation and make it hard to find relevant 
information. I'll probably start/continue the discussion around documentation 
style on the ML.

> 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)

Reply via email to