[JBoss Seam] - Application Permissions
by ptmain
Since many of the old J2EE techniques and patterns are no longer applicable with Seam/JSF/EJB3/etc., I'm curious about what folks are doing for application permissions.
BTW, I'm not referring to login security, but rather to the use of permissions to control access to parts of the application (and provide error messages indicating the missing permission).
Most app servers implement a two-level system of users and groups. However, this doesn't fit my personal view of an application.
In my model, you have a fixed set of Permissions that are required to either access particular pages or enable pieces of functionality within a page. Users and Roles (a.k.a. Groups) are business entities defined and managed by the application's administrator(s). That is, Users have one or more Roles, and Roles are a grouping of permissions that can change daily as the business needs change (now we need the AccountManager role to be able to XYZ).
To be clear, I don't want ANY hard-coded (or configured in XML) Roles, as those are defined by the changing needs of the business.
I've never had much luck using the app server's permission logic, for a couple of reasons:
1. My Permissions equate to the app server's Groups, creating a logical mismatch.
2. There is not always a clear entry point for the app server to control. That is, I don't want to control access to EJBs or methods, it's really the logical entity of a page that I want to control. More to the point, I hate configuring security in my web.xml file.
This is where I get mixed up about where to start in this brave new world of JSF and Seam. In my Struts confort zone, I implemented the permission check in my base Struts action. Each logical page consisted of an Action/JSP pair, and this made it simple to control at the entry point.
Now, in the world of listeners, I've lost my equilibrium. I don't have a clear entry point for a page, because I don't have a good feel for what the "logical page" consists of. I could control access at the JSP level, but that seems to mean that the server side code will execute even if the user doesn't have permission, and I'd be blocking access to the view itself. Argh - I'm sure there's a simple solution: I just don't have solid ground underfoot right now.
This seems like a job for Interceptor Man! But again, what am I intercepting, and how to I implement it? Aside from hardcoded permission checks within a page implementation (e.g. show the delete button if they have permission), I prefer to store the mapping of "pages" to "permissions" in the database. That gives me the most flexibility in terms of redefining dynamic behavior [for example, allowing particular customers to define their own permission mappings, or perhaps add to a fixed set].
Any ideas out of all of this rambling?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964380#3964380
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964380
19 years, 9 months
[JBoss jBPM] - Re: Error in node-->TaskNode
by harderwu
again!
that is misspelled!!
ProcessDefinition:
<start-state name="a">
| <transition name="tra" to="b">
| </transition>
| </start-state>
| <task-node name="b">
| <task name="first">
| <assignment class="com.test.assignment.PartMaster" config-type="bean">
| <groupName>leader</groupName>
| </assignment>
| </task>
| <transition name="tra2" to="c">
| </transition>
| </task-node>
first,I can get a object of transition that name is "tra",
but there is an error when i get the object of tasknode by the transition.getTo()
TaskNode tasknode = (TaskNode) transition.getTo();
there is not the error if i get the object of node by by the transition.getTo()
| Node node = (Node) transition.getTo();
i know the node is the father class of the tasknode, i had seen the code in the exmaple of org.jbpm.test:
public void testTaskNode() {
| ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(
| "<process-definition>" +
| " <task-node name='t' signal='first-wait' create-tasks='false'>" +
| " <task name='change the world once' blocking='true'>" +
| " <assignment class='anyonebutme' />" +
| " </task>" +
| " <task name='change the world twice' />" +
| " <task name='change the world three times' />" +
| " </task-node>" +
| "</process-definition>"
| );
|
| processDefinition = saveAndReload(processDefinition);
|
| TaskNode taskNode = ( TaskNode ) processDefinition. getNode("t");
| }
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964373#3964373
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964373
19 years, 9 months
[JBoss Seam] - Re: EntityManager: For newbies or to close gaps in your know
by bfo81
Wiki
Yes, I intended to put that in the wiki, but first I wanted it to be reviewed ;).
Why is Id Long?
- Integer might be too small *g*
- Using a hull class (Long instead of long) makes it easy to have entities without Id (necessary in transient/new or removed state), since the Id can be "null" then. You could use long (the primitive, not the hull class), but then you would need to explicitely define a "no id state" (e.g. -1 or 0) as far as I know.
- It's also possible to define other "simple" classes, e.g. String as an Id. This could be useful e.g. for unique usernames. Even "complex" classes can be used via @EmbeddedId, and those complex classes need to be annotated with @Embeddable... but ...WHOW... this is going way to far for a newbie tutorial and I cannot think of many useful cases ;).
Flush at method boundary
Thanks for that hint. That's what I didn't know. However, sometimes it's useful to flush before, e.g. to easily recognize database constraint violations and then add a message and perform a rollback.
Rollback on Exceptions
- There's something I'd like to add: When saying "rollback" I usually talk about rollbacks of EJB transactions! Usually changes are made to an entity during a method invocation. If everything works fine, flush() is performed at method end. If an exception occured or setRollbackOnly() was called, then flush() will not be called. So the database remains untouched, but the entity keeps its "dirty" data for now. That's how EJB transactions work. Other case: flush() is explicitely called in the method. Then EJB starts a database transaction and sends the update/insert/delete statements to the database. If the method ends without exceptions, then the database commit will be called, otherwise the database transaction will be rollbacked. So please distinguish between EJB and database transactions ;). I hope I made clear how they work together. (All I said here is what I observed, and it seems to be sensible to me).
- Well, I talked about RuntimeExceptions as you cannot compile without catching "normal" exceptions. Ok, you can add "throws Exception" to your method signature in order to see what happens if normal exceptions occur. This doesn't make sense since the page you're on will crash, but even in this case a rollback will be performed (I just tested it ;)). But all in all you're right, rollbacks happen after all types of exceptions, but usually you catch normal exceptions ;).
btw: It's never a fault to add try...catch... around critical blocks in order to keep your app in a fine state. Catch exceptions, add a message to the user, and explicitely use ejbctx.setRollbackOnly() (@Resource javax.ejb.SessionContext ejbctx). Otherwise your app will crash with ugly exception stacktraces shown to the user - and though the transaction might be rollbacked automatically this just ain't beautiful ;).
- I think that it's EJB3 that cares about the exception since it even cares about the transaction. But I'm not 100% sure about that. Maybe the experts can say something about that ;).
Seam Managed Persistence Context
I must confess that I never ran into LazyInitializationExceptions (abbr. LIE). I use an Extended Persistence Context in a Conversation scoped Stateful Session Bean. And when accessing related entities the EntityManager lazily fetches them without complaint. Don't ask me why. Maybe you can add a case where the LIE occurs.
List, setParameter
Jep, you're right ;).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3964372#3964372
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3964372
19 years, 9 months