Sorry for not having made myself clear enough. I kind of expected it.
It's not a problem to secure my pages/folders by using for example
@Secured(SomeLoggedInAccessDecisionVoter.class)
The main problem arises when I have to handle the "not-logged-in" case
differently.
If it was only one login page I could use "DefaultErrorView" to be redirected
to that page in case of not being logged in.
But if there are different login pages for different parts of the application I
don't know what to do.
Maybe using @ExceptionHandler could help?
BTW, if I don't define a DefaultErrorView and I just add a SecurityViolation in
checkPermission of my AccessDecisionVoter I run into a NPE:
java.lang.NullPointerException
at
[email protected]//io.undertow.servlet.spec.HttpServletRequestImpl.getRequestDispatcher(HttpServletRequestImpl.java:957)
at
[email protected]//com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:692)
at
[email protected]//javax.faces.context.ExternalContextWrapper.dispatch(ExternalContextWrapper.java:91)
at
[email protected]//com.sun.faces.application.view.JspViewHandlingStrategy.executePageToBuildView(JspViewHandlingStrategy.java:356)
at
[email protected]//com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:106)
at
[email protected]//com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:78)
at
[email protected]//com.sun.faces.lifecycle.Phase.doPhase(Phase.java:76)
at
[email protected]//com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:199)
at
deployment.cdi-jsf-0.0.1-SNAPSHOT.war//org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:111)
at
[email protected]//javax.faces.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:88)
at
deployment.cdi-jsf-0.0.1-SNAPSHOT.war//org.apache.deltaspike.jsf.impl.listener.request.JsfClientWindowAwareLifecycleWrapper.render(JsfClientWindowAwareLifecycleWrapper.java:160)
at
[email protected]//javax.faces.webapp.FacesServlet.executeLifecyle(FacesServlet.java:708)What
am I doing wrong here?Original Message processed by david®
Re: Differently secured JSF pages 21. August 2019, 22:16 Uhr
Von Thomas Andraschko
An [email protected]
You can secure directories / single views with DeltaSpike TypeSafe
ViewConfig + Security:
http://deltaspike.apache.org/documentation/jsf.html#Type-safeView-Configs
Am Mi., 21. Aug. 2019 um 20:13 Uhr schrieb Stephen More <
[email protected]>:
> IMO this is not a deltaspike issue.
>
> For security take a look at https://www.pac4j.org/
>
> Usually you have 1 page that logs in all users - Authentication
> Then you assign roles to that user - Authorization
>
> To secure your page utilize isUserInRole(*"ADMIN");*
>
> https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#isUserInRole(java.lang.String)
>
>
> On Wed, Aug 21, 2019 at 11:21 AM Tappe, Heiko <[email protected]> wrote:
>
> >
> > I am in the process of migrating some seam 3 based app to deltaspike.
> > Right now my problem is how to secure my pages. The examples I've seen so
> > far work with a simple and single login.
> > But my app uses different logins for different parts of the app. For
> > example
> > - Standard login for /pages/*
> > - Admin login for /adminpages/*
> > What I would like to achieve is that when requesting a page without being
> > logged in to be redirected to the appropriate login page and after
> > successful login the original page (with all its request params) is to be
> > shown.
> > Though sometimes right after a successful login one or two more info
> pages
> > are to be shown before the original page comes back into play.
> > If the user tries to access for instance an admin page though logged in
> as
> > a standard user (or the other way round) an error page should be
> displayed.
> >
> >
> > Any idea how to achieve this?
> >
> >
> > --Heiko
> >
>
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virenfrei.
http://www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
