Road Map

[gavin.king]

I have mapped out a proper road map in JIRA:

http://jira.jboss.com/jira/browse/JBSEAM?report=com.atlassian.jira.plugin.system.project:roadmap-panel

(click "all versions" to see out to 1.2.0.BETA1)

This is an aggressive plan, so please don't yell at us if releases slip somewhat.

UPDATE:

More info on the roadmap here:

http://blog.hibernate.org/cgi-bin/blosxom.cgi/2006/12/14#roadmap

[rlhr]

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

[cavani]

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,

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

[js8523]

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

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

[amitev]

How about implementing synchronizer token in seam?

[gavin.king]

How about implementing synchronizer token in seam?

A what?

[amitev]

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.

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

[perwik]

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?

[shane.bryzak]

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.