[
https://issues.jboss.org/browse/SEAMFACES-209?page=com.atlassian.jira.plu...
]
John Ament commented on SEAMFACES-209:
--------------------------------------
I worked with Cody a bit on this one in IRC. He did not have any @RestrictAtPhase
specified for his security binding. this resulted in some odd behavior. I can't
tell, doesn't look like there is a default for this annotation when not present, so
I'm not sure what should have happened. Maybe we either require it to be present, or
use a default like RESTORE_VIEW when not present?
Either way, the work around was for him to specify
@RestrictAtPhase(PhaseIdType.RESTORE_VIEW) to correctly secure his pages.
Security integration shows denied pages
---------------------------------------
Key: SEAMFACES-209
URL:
https://issues.jboss.org/browse/SEAMFACES-209
Project: Seam Faces
Issue Type: Bug
Components: Security
Affects Versions: 3.1.0.Beta2
Reporter: Nicklas Karlsson
Assignee: Jason Porter
Fix For: 3.1.0.Final
I have a @ViewConfig and security annotated page that fails the auth check but the code
in SecurityPhaseListener
private void redirectToAccessDeniedView(FacesContext context, UIViewRoot viewRoot) {
// If a user has already done a redirect and rendered the response (possibly in
an observer) we cannot do this output
if (!(context.getResponseComplete() || context.getRenderResponse())) {
quietly fails the check and then proceeds to render the page. It should perhaps throw an
exception or take some other actions to at least deny the page.
In an unrelated note, I can't see where response output would be produced since I
just edited the browser url and pointed it at a forbidden page...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira