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