-
1. Re: Road Map
rlhr Nov 17, 2006 3:18 AM (in response to gavin.king)I went through the road map and I must say I'm really excited to what's coming up :)
Thanks a lot for the hard and good work.
Richard -
2. Re: Road Map
cavani Nov 17, 2006 6:57 AM (in response to gavin.king)Amazing...
My only concern is that the Security Feature Request is not separated in minor features for individual voting... I'm interested in Seam's JAAS support over JSF on Facelets (no j_security_check form action) through Login action bean...
any ways... that's a good plan... congrats!!
Thanks a lot, -
3. Re: Road Map
gavin.king Nov 17, 2006 11:29 AM (in response to gavin.king)Note that the security stuff is in heavy flux. Shane and I and the Drools guys have been having some discussions about what will be the final form of this stuff and its turning out pretty interesting (a LOT different to the standard Java EE security). So anyway, thats why it isn't broken down into smaller tasks.
-
4. Re: Road Map
js8523 Nov 17, 2006 3:41 PM (in response to gavin.king)Re: Seam security stuff.
Is this also up for discussion with the Portal and Jbpm guys, as I remember you stating a while ago that you would like to see standardisation between the products?
Thanks
James -
5. Re: Road Map
gavin.king Nov 17, 2006 4:36 PM (in response to gavin.king)Yeah, but that is outside of the current scope of work. At some stage we need a unified identity model for all projects, but that won't happen in this work.
-
6. Re: Road Map
amitev Dec 19, 2006 6:24 AM (in response to gavin.king)How about implementing synchronizer token in seam?
-
7. Re: Road Map
gavin.king Dec 19, 2006 10:04 AM (in response to gavin.king)How about implementing synchronizer token in seam?
A what? -
8. Re: Road Map
amitev Dec 19, 2006 10:31 AM (in response to gavin.king)This text is from core j2ee patterns [1]:
Synchronizer Token
This strategy addresses the problem of duplicate form submissions. A synchronizer token is set in a user's session and included with each form returned to the client. When that form is submitted, the synchronizer token in the form is compared to the synchronizer token in the session. The tokens should match the first time the form is submitted. If the tokens do not match, then the form submission may be disallowed and an error returned to the user. Token mismatch may occur when the user submits a form, then clicks the Back button in the browser and attempts to resubmit the same form. -
9. Re: Road Map
gavin.king Dec 19, 2006 10:38 AM (in response to gavin.king)Um, what can I say. *shakes head in frustration*
Did you realize that Seam has MUCH more sophisticated mechanisms for this stuff that any shitty "J2EE (anti-)patterns"?
Begin a conversation when rendering the form, and end it when the operation has been successful.
The user *should* be allowed to use the backbutton, right up until the point at which the operation succeeded. -
10. Re: Road Map
perwik Dec 28, 2006 8:54 PM (in response to gavin.king)I just took a look at Seam in the CVS and after going through the seamspace example I can't say anything else than:
I love you guys! :-)
I've been putting off this project for a long time in lack of a good security implementation and now you've solved a lot of my problems.
I know you've planned to work on the security release for at least three more weeks (according to http://jira.jboss.com/jira/browse/JBSEAM?report=com.atlassian.jira.plugin.system.project:roadmap-panel) but I've got something that you might not have thought of:
In security-config.xml you specify roles and assign permissions to them. What I would like is to specify somewhere which permissions exists and what actions they can have. Something like:<permissionDefinition> <name>user</name> <action>create</action> <action>modify</action> <action>delete</action> </permissionDefinition> <permissionDefinition> <name>account</name> <action>create</action> <action>delete</action> </permissionDefinition>
and then I could assign them to roles in the security-config OR I could create roles on the fly from the application and pick permissions from some sort of gui based on the initial permissions definition. Perhaps this sound totally crazy, or you've already done it, what do I know :-)
An other thing that I came to think of:
Now the permissions store their name and action as strings. Wouldn't the use of enums or something else that is typesafe make life easier for us? I'd hate to have a bug where I misspelled one of the strings somewhere. Or did I miss something? -
11. Re: Road Map
shane.bryzak Dec 29, 2006 8:05 AM (in response to gavin.king)You'll be able to extend SecurityConfiguration to load roles/permissions from a database if you like, however keep in mind that these are only explicitly assigned permissions, as opposed to the dynamic rule-based permissions that the security API will also support.
As for enums, the type safety would be nice however permissions can have any name (eg customer.doSpecialAction) so that unfortunately rules them out.