[ https://jira.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated SEAMFACES-33: ---------------------------------------- Summary: Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting configuration (was: Create a solution for consolidated page-flow, transactional control, security constraints and URL-rewriting) Component/s: Configuration API (was: Conversations) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plugin... ] Lincoln Baxter III updated SEAMFACES-33: ---------------------------------------- Affects Version/s: 3.0.0.Alpha4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Shane Bryzak updated SEAMFACES-33: ---------------------------------- Fix Version/s: 3.0.0.Beta3 (was: 3.0.0.Beta1) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Shane Bryzak updated SEAMFACES-33: ---------------------------------- Priority: Blocker (was: Major) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Shane Bryzak updated SEAMFACES-33: ---------------------------------- Fix Version/s: 3.0.0.Final (was: 3.0.1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Dan Allen commented on SEAMFACES-33: ------------------------------------ I'll mention that I did have the restrict view implemented at one point using the JSF system events, but it got cut. See SEAMFACES-79. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Stuart Douglas reassigned SEAMFACES-33: --------------------------------------- Assignee: (was: Stuart Douglas) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Brian Leathem commented on SEAMFACES-33: ---------------------------------------- At first glance, the @ViewConfig enum and view data store solution seems like a great fit. I would like to see support for configuring the ViewData via tags in the facelet metadata. Brainstorming with Stuart, it seems reasonable to have a phase listener that parses the component tree of a view, and dynamically builds the ViewData on first visit. We would then be able to support ViewData configuration via the @ViewConfig enum, as well as <f:metadata> tag overrides for transactional control, security constraints and URL-rewriting. This would be ideal in my opinion. However, pursuing the metadata tag configuration should be treated with a separate issue (possibly post 3.0.0.Final), and we should focus on creating the annotations and phase listeners to support security constraints and URL-rewriting. (Stuart has already created the annotations, and a phase listener for transactional control.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Shane Bryzak commented on SEAMFACES-33: --------------------------------------- I like @ViewConfig also, it's less ambiguous than @ViewData. The <f:metadata> idea is great, I really like it. For now though, let's just go with the enum-based configuration and proceed as you suggest Brian by creating a separate JIRA feature request for alternative configuration options. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Brian Leathem commented on SEAMFACES-33: ---------------------------------------- I had initially thought of creating a Faces @Restrict tag, that would use EL to grant/deny access to a page. Shane pointed out we should rather be using the typesafe security annotations from Seam security (an optional Dependency). The app dev would build annotations that are annotated with @SecurityBindingType, and put these annotations in the @ViewConfig enum. Faces will listen for the PostConstructViewMapEvent, retrieve the list of @SecurityBindingType annotations from the @ViewConfig, then throw a CheckSecuredViewEvent. The Seam Security module will observe it, do the security check, and return a boolean. Not as straightforward as @Restrict(#{expersionLanguage}), but type safety is definitely a big benefit. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Brian Leathem updated SEAMFACES-33: ----------------------------------- Fix Version/s: 3.0.0.Final (was: 3.0.0.CR2) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Brian Leathem edited comment on SEAMFACES-33 at 3/20/11 7:44 PM: ----------------------------------------------------------------- Updates for those following along: # Class Renames. I renamed @ViewData to @ViewPattern, and everything else is named @ViewConfig[Something], all in the "org.jboss.seam.faces.view.config" package. This naming convention is a strawman proposal - I'd like to get the API working, and put it out there for community feedback. # The @ViewConfig annotation enums wan't being picked up by Weld 1.1, so I switched to using an interface, with @ViewPattern annotations on methods. Slightly more cumbersome - but it works! # Some ideas for refinements on Security options ## timing for security enforcement is (depending on request type): initial | postback = AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER default timing is initial = BEFORE_RENDER, postback = AFTER_RESTORE ## view to redirect to on authentication failure: ### if not logged in, redirect to a login page ### if logged in, and auth fails, redirect to an error page by default, with option of providing an "auth failed view" via anotation or parameter was (Author: bleathem): Updates for those following along 1) Class Renames. I renamed @ViewData to @ViewPattern, and everything else is named @ViewConfig[Something], all in the "org.jboss.seam.faces.view.config" package. This naming convention is a strawman proposal - I'd like to get the API working, and put it out there for community feedback. 2) The @ViewConfig annotation enums wan't being picked up by Weld 1.1, so I switched to using an interface, with @ViewPattern annotations on methods. Slightly more cumbersome - but it works! 3) Some ideas for refinements on Security options 1) timing for security enforcement is (depending on request type): initial | postback = AFTER_RESTORE | BEFORE_INVOKE | BEFORE_RENDER default timing is initial = BEFORE_RENDER, postback = AFTER_RESTORE 2) view to redirect to on authentication failure: 1) if not logged in, redirect to a login page 2) if logged in, and auth fails, redirect to an error page by default, with option of providing an "auth failed view" via anotation or parameter -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Brian Leathem updated SEAMFACES-33: ----------------------------------- Description: We need a solution to address consolidated page-flow, transactional control, security constraints, and perhaps URL-rewriting -- all in one place. It has been previously discussed that a type-safe API be possible for this - which is definitely preferred over XML configuration: http://lists.jboss.org/pipermail/seam-dev/2010-February/002003.html was: We need a solution to address consolidated page-flow, transactional control, security constraints, and perhaps URL-rewriting -- all in one place. It has been previously discussed that a type-safe API be possible for this - which is definitely preferred over XML configuration: http://old.nabble.com/Replacing-pages.xml-td27649799.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SEAMFACES-33?page=com.atlassian.jira.plug... ] Brian Leathem updated SEAMFACES-33: ----------------------------------- Description: We need a solution to address consolidated page-flow, transactional control, security constraints, and perhaps URL-rewriting -- all in one place. It has been previously discussed that a type-safe API be possible for this - which is definitely preferred over XML configuration: http://lists.jboss.org/pipermail/seam-dev/2010-February/002003.html http://lists.jboss.org/pipermail/seam-dev/2010-March/002053.html http://lists.jboss.org/pipermail/seam-dev/2010-July/002812.html was: We need a solution to address consolidated page-flow, transactional control, security constraints, and perhaps URL-rewriting -- all in one place. It has been previously discussed that a type-safe API be possible for this - which is definitely preferred over XML configuration: http://lists.jboss.org/pipermail/seam-dev/2010-February/002003.html http://lists.jboss.org/pipermail/seam-dev/2010-July/002812.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira