[
http://jira.jboss.com/jira/browse/JBSEAM-1224?page=comments#action_12360160 ]
Jim Hazen commented on JBSEAM-1224:
-----------------------------------
I don't know if there's a generic approach to security to be applied here. I was
only suggesting a nod be given to it and that crud pages not be written with reckless
abandon. That said, I wonder if either a subclass or a Home + composition of an access
decider could enhance security a bit. Seam appears to provide most of this already via
@Restrict. However as far as I can tell, this method doesn't work unless you're
able to annotate the entity source and access the main securityRules.drl. What about
cases in which this isn't possible? Can these restrictions be defined via
components.xml? Can securityRules.drl be broken up and shipped with a packaged entity,
like pages.xml can be broken up for navigation?
I wish I had more than just an uneasy feeling. I'll think about this a little more.
Consider integration of security with App Framework
---------------------------------------------------
Key: JBSEAM-1224
URL:
http://jira.jboss.com/jira/browse/JBSEAM-1224
Project: JBoss Seam
Issue Type: Feature Request
Components: Core, Security
Affects Versions: 1.2.1.GA
Reporter: Pete Muir
Assigned To: Shane Bryzak
From the forums:
'One down side to using EntityHome for generic crud is lack of built in security.
One needs to be careful when using Homes for crud operations that allow or require
RequestParameters. You need to ensure the operation on this ID is valid. You don't
want to expose information you shouldn't and you definitely don't want to modify
or destroy information you shouldn't.
For example, you don't want a user to update or delete another user's entity just
by changing an ID in the URL and hitting return. Seam supports entity level security and
you can probably extend a Home to double check access restrictions prior to operations.
Likewise, you don't want private information available on lets say a user profile
screen, to be available to anyone able to modify a URL.'
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira