Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-07-31 20:16:27
|
I've just committed extensive polishing and several new features for the = transaction package etc, i.e. all my stuff from the last few days: - support for Hibernate flush modes on HibernateTemplate and = HibernateInterceptor; - support for read-only transactions via a new = TransactionDefinition.readOnly property: DataSourceTransactionManager = and HibernateTransactionManager actually support this via = Connection.setReadOnly and Hibernate's FlushMode.NEVER; - fixed rollback exception handling: if the rollback operation itself = throws an exception, the application exception's stacktrace gets logged = now, and the transaction system exception thrown; - reworked TransactionAttributeSourceEditor: supports "readOnly" = keyword, and the other keywords in any order now (like = "+RemoteException,readOnly,ISOLATION_READ_COMMITTERD,PROPAGATION_REQUIRED= "); - reworked MapTransactionAttributeSource: can also be used as bean, to = specify a "methodMap" method/attribute map that allows for bean = references to fully configurable DefaultTransactionAttribute instances; - application context includes via XML entities: the new = ResourceBaseEntityResolver resolves such entities relative to the = resource base of the application context now, allowing for splitting = context definitions into multiple files; - DAO base classes: the new JdbcDaoSupport, HibernateDaoSupport, and = JdoDaoSupport classes in respective support packages can serve as = convenient base classes for DAOs that use the templates; - HandlerInterceptor.postHandle: the web interceptor framework supports = postHandle now in addition to preHandle, allowing e.g. for binding user = contexts from a session attribute to a ThreadLocal in preHandle and = removing it again in postHandle. Anyone who can find the time, please try the current CVS contents, and = review the changes if you like. That's it for 0.9.1 from me. Juergen DI J=FCrgen H=F6ller Senior System Architect ______________________________________ werk3ATS - division systementwicklung part of werk3AT internetmedien oeg europaplatz 4 A - 4020 linz t. +43 (0) 732 71 65 29 502 f. +43 (0) 732 71 65 29 3 jue...@we... www.werk3at.com ______________________________________ werk3ATS - WIR ENTWICKELN ERFOLG |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-07-31 21:36:44
|
> interceptor framework supports postHandle=20
> now in addition to preHandle, allowing e.g.=20
> for binding user contexts from a session=20
> attribute to a ThreadLocal in preHandle=20
> and removing it again in postHandle.
Argggh.... I just spent my time breaking my mind over the issue how to
do this (and shouting at the framework for not having
postHandlerInterceptors ;-). Then I get this email ;-). So to implement
the latest and greatest of my features, I will probably have a chance to
test this quite thoroughly tomorrow. Some of those features might - btw
- be very interesting for addition to Spring, but definitely not for
0.9.1 release!!!
Ahh, what the heck, why don't I just already put up the ideas, maybe
people have some interesting thoughts... What I'll describe below is
already implemented in a working prototype.
--- WARNING - NOT FOR THE 0.9.1 RELEASE, JUST A TWIST OF THE MIND ---
I've been struggling for ever with the question how to prevent certain
users from seeing or being able to edit certain data. And then I don't
mean complete objects, just bits of objects. For instance:
administrators can create and edit Account-objects, users in their turn
can only update their firstName-property and lastName-property
(contained by those accounts). I really don't want to - every time I
save the Account object - check if the user isInRole(user/administrator)
and check if the firstName-property and lastName-property has been set,
etcetera. I also don't want to have those checks in my
datamodel/objects. It would be perfect if this could done outside the
datamodel and also outside the businesslogic. Just like validation. Oh
yeah, I don't want to do it with database-views...
So today I had a huge fight (design sessions are always fights here, but
it's very constructive) with my colleague about this issue. We finally
came up with the idea to think up a generic Object/PropertyPermissions
framework, of which he would make the implementation that would set
permissions based on the combination of Object type and Role (contained
by the Principal).
To be able to use this in MVC (and more specifically: Spring), I have
devised something like the Validator (contained in a new package
com.interface21.security), called PropertyPermissionsResolver. This
works together with the PropertyPermissions interface and the
PropertyPermissions interface. All very abstract and to be implemented
just as the validator.
PropertyPermissions would apply to the complete Model (in the
ModelAndView) and objects in the model will dynamically be passed to the
PropertyPermissionInspector (having the same boolean supports()-method
as the Validator). So if no Inspector is defined for a certain Object,
no permission will be added (or nothing is accessible at all, this would
be configurable).
Views can use the information of the PropertyPermissions and stuff in
their logic to render things accordingly. To facilitate JSP Views I want
to a couple of method to the BindStatus object - or extending it for
this purpose - (specifically isVisible() and isEditable()) to be able to
use the BindStatus for this purpose as well=85 JSP code utilizing this
would somewhat look like this:
<spring:bind path=3D"Account.active">
<c:if test=3D"${status.editable}">
<intput type=3D"text" name=3D"<c:out
value=3D"${status.epxression}"/>" value=3D"<c:out
value=3D"${status.value}"/>">
</c:if>
</spring:bind>
<spring:bind path=3D"Account.fistName">
<c:if test=3D"${status.editable}">
<input type=3D"text" name=3D"<c:out
value=3D"${status.epxression}"/> value=3D"<c:out =
value=3D"${status.value}"/>">
</c:if>
</spring:bind>
The above code would result in two textfields for the administrator
(both active and firstName) and one textfield for anybody with role
'user' when applying the usecase mentioned above (if of course you would
be using the Role/ObjectType based security model!). So only one view,
one controller, one model but still hiding certain property from certain
users that are not allowed to see them (and a lot more possible
functionalities ;-).
Right now I've got things implemented for Roles/ObjectTypes and this
looks like the following. As you might see, nested property permission
are possible using this thing as well=85 This is all pretty specific for
our application and way of working, but the interfaces
(PropertyPermissions, Inspector, Resolver and stuff) and the complete
idea is especially suitable for addition in my opinion, even more since
Juergen just added the postHandle things, where this can take place...
<object-permission name=3D"jteam.site.data.Account">
<!-- everybody is allowed to see everything -->
<property-permission>
<role-name>administrator</role-name>
<role-name>employee</role-name>
<property-name>*</property-name>
<editable>true</editable>
<visible>true</visible>
</property-permission>
<!-- the customer cannot edit an account -->
<property-permission>
<role-name>customer</role-name>
<property-name>*</property-name>
<editable>false</editable>
</property-permission>
<!-- define the properties that are nested -->
<object-permission-ref property=3D"account"
ref=3D"jteam.site.data.Account"/>
</object-permission>
However, I've got a couple of issues hanging around=85
* The BindStatus things are pretty JSP-specific of course. How to
use PropertyPermissions when one's View technology is Velocity? I don't
want to (before the view gets rendered) generate all PermissionsObjects
up front, because this is all nested and it could well be 100's of
objects each request (of which probably only 10% is actually used,
considering a form of 10 fields)
* What to do with the PropertyPermissionsInspector. There's no
place - so far I can see - to put the PropertyPermissions in. I kind of
sense they should be part of the model (in the ModelAndView object), but
this of course is a major api-change. PropertyPermissions should be
usable in any view, not just for instance the JSP view. So somehow the
Inspector needs to be available at all times...
* How to actually get in the functionality that it=92s not only
possible to see if a property is editable, but also to prevent the
setter from being called. I smell a bit of AOP here (and I'm not too
familiar with it yet), but is it possible to create advises and
interceptor dynamically using a security configuration file or
something?
* How to get extra information in for use when developing custom
propertypermissioninspectors. Right now I need to have the principal to
determine the role of the user and I'm passing on the HttpServletRequest
to achieve this=85 But this does not feel right (see the methods below)
Phew=85 that's all basically. Below I'll insert the public API for the
object I've mentioned, just so you can take a look=85
/* this one is resembling Errors a lot */
Interface PropertyPermissions
---- // final static permission integer
---- boolean isVisible(String path)
---- boolean isEditable(String path)
---- boolean setNestedPath(Sring nested)
---- void permit(String field, int permissions)
/* this is the interface actually determining the permissions */
Interface PropertyPermissionInspector
---- boolean support(Class clzz)
---- /* passing on the servletrequest does not feel right, but see the
remark above */
---- PropertyPermissions determinePropertyPermissions(Object o,
HttpServletRequest req)
/* this is the to-be-configured collection of Inspector that will be
used
to apply a security model to the complete Model(AndView), names are
crap by the way */
Class PropertyPermissionsResolver
---- /* setter for the propertypermission objects in the xxx-servlet.xml
*/
---- void setPropertyPermissionsInspector(List l)
---- /* finds inspector supporting given class and returns
PropertyPermissions */
---- PropertyPermissions getPropertyPermissions(request, response,
object)
This all would be used from a PostSecurityHandlerInterceptor which I
haven't created yet=85.
Opinions???
Alef
|
|
From: Timo V. <sic...@gm...> - 2003-08-01 07:49:14
|
Hi all!
I'm quite new to the spring framework. I started evaluating it about a=20
month ago. So if the following appears odd it might be due to my lack=20
of experience.
Currently, if I were to build a project with the Spring framework, I=20
would build my layers as follows:
C - [ depends on project ]
B - POJO Business Objects
A - POJO DAO Objects (Hibernate in my case)
Objects in each layer may only call other Object in the same layer or=20
Objects in the NEXT lower layer.=20
Given I was to build an EJB solution, layer C would be a SINGLE session=20
facade SLSB (single because I want to avoid COSTLY inter EJB calls).=20
=46or testing/QA, I would write unittests at layer C to test B and A, and=20
maybe unittests at layer D to test the SLSB. For maintenance=20
(developers only) I could write another POJO java-app running at C. If=20
I wanted to CHANGE the solution-type from EJB to webinterface I could=20
either replace the SLSB at C with servlets/jsps/etc. or write a=20
servlet/jsp/etc. layer at D using EJB layer C.
Layers A and B do NOT contain ANY features the EJB container can provide=20
at C, i.e. no TX demarcation, no security, etc.. So if I have a layer=20
at C that is not EJB I CAN (but do not HAVE TO) implement these=20
features myself. In case of testing/QA layers A + B I'm HAPPY that I'm=20
not EJB dependent and that I do not have to "code around" security=20
measures! For developer controlled maintenance code at layer C I'm=20
HAPPY that I do have to care about security and TX (in maintenance mode=20
its only me connected to the system). And in case I change from EJB to=20
web-solution I have the CHOICE whether I want the benefits (and=20
overhead) of using EJB at C with web at D or wheter I want web at C,=20
where I would have to manually care about security and TX demarcation.
The above appears VERY FLEXBILE to me. If I got you right, you would=20
like to add security at layer A. This would screw up the model at=20
various points (my problem - I do not have to use those security=20
features). Furthermore, it might not be a good idea to have a depency=20
in a Spring security API on SPECIFIC other security providing=20
frameworks such as EJB and Servlets - relying on the Principal=20
interface sort of introduces such a dependency, though.
Please don't get me wrong: These are mainly my thoughts on how your=20
proposal would affect my current model...=20
Just my 2c,
Timo
Am Donnerstag, 31. Juli 2003 23:26 schrieb Alef Arendsen \(JTeam\):
> > interceptor framework supports postHandle
> > now in addition to preHandle, allowing e.g.
> > for binding user contexts from a session
> > attribute to a ThreadLocal in preHandle
> > and removing it again in postHandle.
>
> Argggh.... I just spent my time breaking my mind over the issue how
> to do this (and shouting at the framework for not having
> postHandlerInterceptors ;-). Then I get this email ;-). So to
> implement the latest and greatest of my features, I will probably
> have a chance to test this quite thoroughly tomorrow. Some of those
> features might - btw - be very interesting for addition to Spring,
> but definitely not for 0.9.1 release!!!
>
> Ahh, what the heck, why don't I just already put up the ideas, maybe
> people have some interesting thoughts... What I'll describe below is
> already implemented in a working prototype.
>
> --- WARNING - NOT FOR THE 0.9.1 RELEASE, JUST A TWIST OF THE MIND ---
>
> I've been struggling for ever with the question how to prevent
> certain users from seeing or being able to edit certain data. And
> then I don't mean complete objects, just bits of objects. For
> instance:
> administrators can create and edit Account-objects, users in their
> turn can only update their firstName-property and lastName-property
> (contained by those accounts). I really don't want to - every time I
> save the Account object - check if the user
> isInRole(user/administrator) and check if the firstName-property and
> lastName-property has been set, etcetera. I also don't want to have
> those checks in my
> datamodel/objects. It would be perfect if this could done outside the
> datamodel and also outside the businesslogic. Just like validation.
> Oh yeah, I don't want to do it with database-views...
>
> So today I had a huge fight (design sessions are always fights here,
> but it's very constructive) with my colleague about this issue. We
> finally came up with the idea to think up a generic
> Object/PropertyPermissions framework, of which he would make the
> implementation that would set permissions based on the combination of
> Object type and Role (contained by the Principal).
>
> To be able to use this in MVC (and more specifically: Spring), I have
> devised something like the Validator (contained in a new package
> com.interface21.security), called PropertyPermissionsResolver. This
> works together with the PropertyPermissions interface and the
> PropertyPermissions interface. All very abstract and to be
> implemented just as the validator.
>
> PropertyPermissions would apply to the complete Model (in the
> ModelAndView) and objects in the model will dynamically be passed to
> the PropertyPermissionInspector (having the same boolean
> supports()-method as the Validator). So if no Inspector is defined
> for a certain Object, no permission will be added (or nothing is
> accessible at all, this would be configurable).
>
> Views can use the information of the PropertyPermissions and stuff in
> their logic to render things accordingly. To facilitate JSP Views I
> want to a couple of method to the BindStatus object - or extending it
> for this purpose - (specifically isVisible() and isEditable()) to be
> able to use the BindStatus for this purpose as well=85 JSP code
> utilizing this would somewhat look like this:
>
> <spring:bind path=3D"Account.active">
> <c:if test=3D"${status.editable}">
> <intput type=3D"text" name=3D"<c:out
> value=3D"${status.epxression}"/>" value=3D"<c:out
> value=3D"${status.value}"/>">
> </c:if>
> </spring:bind>
> <spring:bind path=3D"Account.fistName">
> <c:if test=3D"${status.editable}">
> <input type=3D"text" name=3D"<c:out
> value=3D"${status.epxression}"/> value=3D"<c:out
> value=3D"${status.value}"/>"> </c:if>
> </spring:bind>
>
> The above code would result in two textfields for the administrator
> (both active and firstName) and one textfield for anybody with role
> 'user' when applying the usecase mentioned above (if of course you
> would be using the Role/ObjectType based security model!). So only
> one view, one controller, one model but still hiding certain property
> from certain users that are not allowed to see them (and a lot more
> possible functionalities ;-).
>
> Right now I've got things implemented for Roles/ObjectTypes and this
> looks like the following. As you might see, nested property
> permission are possible using this thing as well=85 This is all pretty
> specific for our application and way of working, but the interfaces
> (PropertyPermissions, Inspector, Resolver and stuff) and the complete
> idea is especially suitable for addition in my opinion, even more
> since Juergen just added the postHandle things, where this can take
> place...
>
> <object-permission name=3D"jteam.site.data.Account">
> <!-- everybody is allowed to see everything -->
> <property-permission>
> <role-name>administrator</role-name>
> <role-name>employee</role-name>
> <property-name>*</property-name>
> <editable>true</editable>
> <visible>true</visible>
> </property-permission>
> <!-- the customer cannot edit an account -->
> <property-permission>
> <role-name>customer</role-name>
> <property-name>*</property-name>
> <editable>false</editable>
> </property-permission>
> <!-- define the properties that are nested -->
> <object-permission-ref property=3D"account"
> ref=3D"jteam.site.data.Account"/>
> </object-permission>
>
> However, I've got a couple of issues hanging around=85
> * The BindStatus things are pretty JSP-specific of course. How to
> use PropertyPermissions when one's View technology is Velocity? I
> don't want to (before the view gets rendered) generate all
> PermissionsObjects up front, because this is all nested and it could
> well be 100's of objects each request (of which probably only 10% is
> actually used, considering a form of 10 fields)
> * What to do with the PropertyPermissionsInspector. There's no
> place - so far I can see - to put the PropertyPermissions in. I kind
> of sense they should be part of the model (in the ModelAndView
> object), but this of course is a major api-change.
> PropertyPermissions should be usable in any view, not just for
> instance the JSP view. So somehow the Inspector needs to be available
> at all times...
> * How to actually get in the functionality that it=92s not only
> possible to see if a property is editable, but also to prevent the
> setter from being called. I smell a bit of AOP here (and I'm not too
> familiar with it yet), but is it possible to create advises and
> interceptor dynamically using a security configuration file or
> something?
> * How to get extra information in for use when developing custom
> propertypermissioninspectors. Right now I need to have the principal
> to determine the role of the user and I'm passing on the
> HttpServletRequest to achieve this=85 But this does not feel right (see
> the methods below)
>
> Phew=85 that's all basically. Below I'll insert the public API for the
> object I've mentioned, just so you can take a look=85
>
> /* this one is resembling Errors a lot */
> Interface PropertyPermissions
> ---- // final static permission integer
> ---- boolean isVisible(String path)
> ---- boolean isEditable(String path)
> ---- boolean setNestedPath(Sring nested)
> ---- void permit(String field, int permissions)
>
> /* this is the interface actually determining the permissions */
> Interface PropertyPermissionInspector
> ---- boolean support(Class clzz)
> ---- /* passing on the servletrequest does not feel right, but see
> the remark above */
> ---- PropertyPermissions determinePropertyPermissions(Object o,
> HttpServletRequest req)
>
> /* this is the to-be-configured collection of Inspector that will be
> used
> to apply a security model to the complete Model(AndView), names
> are crap by the way */
> Class PropertyPermissionsResolver
> ---- /* setter for the propertypermission objects in the
> xxx-servlet.xml */
> ---- void setPropertyPermissionsInspector(List l)
> ---- /* finds inspector supporting given class and returns
> PropertyPermissions */
> ---- PropertyPermissions getPropertyPermissions(request, response,
> object)
>
> This all would be used from a PostSecurityHandlerInterceptor which I
> haven't created yet=85.
>
> Opinions???
>
> Alef
|
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-08-01 08:23:21
|
<quote> C - [ depends on project ] B - POJO Business Objects A - POJO DAO Objects (Hibernate in my case) Objects in each layer may only call other Object in the same layer or Objects in the NEXT lower layer. Given I was to build an EJB solution, layer C would be a SINGLE session facade SLSB (single because I want to avoid COSTLY inter EJB calls). For testing/QA, I would write unittests at layer C to test B and A, and maybe unittests at layer D to test the SLSB. For maintenance (developers only) I could write another POJO java-app running at C. If I wanted to CHANGE the solution-type from EJB to webinterface I could either replace the SLSB at C with servlets/jsps/etc. or write a servlet/jsp/etc. layer at D using EJB layer C. </quote> Well, this isn't very odd! It resembles the way we (and probably a lot Of other people) do things... <quote> The above appears VERY FLEXBILE to me. If I got you right, you would like to add security at layer A. This would screw up the model at various points (my problem - I do not have to use those security features). Furthermore, it might not be a good idea to have a depency in a Spring security API on SPECIFIC other security providing frameworks such as EJB and Servlets - relying on the Principal interface sort of introduces such a dependency, though. Please don't get me wrong: These are mainly my thoughts on how your proposal would affect my current model... </quote> I totally get your point. The way you're working is exactly the same as We do. We call layers A & B (they don't differ much here) the module layer here, the layer above is the component layer containing business logic... Modules can't have security, can't have io, can't have networking etctera (basically all EJB forbids)... The component layer contains transactions/security, etctera. The thing is, that the security model J2EE provides does not meet our demands when it comes to security for __parts of objects__. I'm trying to figure out something to add this. This does not mean I'm intruding on the module level (A+B). You can compare it a lot with the validation framework. We're having the commons validator included as validator for the Spring framework (just extend the validator interface and use the commons validator there). Each data object in our system has a validation.xml file (located right beside the class file, called [class].validation.xml). This means I haven't intruded on the data level, just added a descirptorfile, describing validation rules... No extra interface (I hate that ;-). Same thing holds for the Hibernate stuff... We're using a proprietary little farmework for integration of Hibernate into Spring (would rather have used Spring here, but the framework is already in place for a long time). The Hibernate files are placed right besides the data files and are called [class].hbm.xml. Right now I want to add security. HOW the security is done, is actually determine by the security-implementation (in this cause a RoleObjectPermissionsWhatever, __located at the component level (Spring + C)__, however using the descriptor files from the module level (A+B)... No extra interface or classes to extend, just an extra description. What the criteria for the permissions would be, is totally up to the implementation. In this case I need Role/Principal information, which means I either need the SessionContext/EntityContext or a ServletRequest (whatever, something using JAAS/javax.security). This means the implementation can __never__ be located at the modulelayer (A+B). Other implementations would provide time based permissions (between 2am-3am not possible to edit backup schedule, because backup is actually done then)... Anyway, I hope this clarifies things a little bit and I hope to get some more feedback and stuff (people just shouting __arghh this is ugly__ would do as well!!!)... Thanx, Alef |
|
From: Trevor C. <pr...@se...> - 2003-08-01 14:36:58
|
I think Security might be too large an issue to be addressed in Spring, at least without complicating it even further. While you're idea has promise, there are so many other ways of handling it (such as with db permissions, handling only in certain layers, creating object hierarchies with different methods) that my opinion is we should leave it. Spring's philosophy (IMO) has been about providing a generic core infrastructure that does NOT intrude on the business layer, and does not enforce a specific way of coding (for example the whole JDBC vs EJB vs Hibernate vs JDO is handled seamlessly from the perspective of the business layer). I would vote against adding the sort of handling you're describing. That being said, we have run into some of the issues you're discussing in our programming over the last few months on a Spring-based web-app. We solved our problem through custom taglibs in the (jsp) web layer (this handles accessors), and you can use a custom binder (instead of the default from BindUtils) which receives the request object (so has access to security info) before processing each object. I'm not quite up-to-speed on the current codebase, so Juergen may have a "quick-tip" on how best to override the binder used. AOP also looks very promising, although I have yet to get into it. Basically, Spring provides many ways for you to handle your problem according to your needs, but I don't think we can generalize the (security) solution, only the tools (Spring) to deal with it as needed. My 2 cents. Trevor D. Cook -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Alef Arendsen (JTeam) Sent: August 1, 2003 4:24 AM To: 'Timo Verhoeven'; spr...@li... Subject: RE: [Springframework-developer] polishing and new features - security model?????? <quote> C - [ depends on project ] B - POJO Business Objects A - POJO DAO Objects (Hibernate in my case) Objects in each layer may only call other Object in the same layer or Objects in the NEXT lower layer. Given I was to build an EJB solution, layer C would be a SINGLE session facade SLSB (single because I want to avoid COSTLY inter EJB calls). For testing/QA, I would write unittests at layer C to test B and A, and maybe unittests at layer D to test the SLSB. For maintenance (developers only) I could write another POJO java-app running at C. If I wanted to CHANGE the solution-type from EJB to webinterface I could either replace the SLSB at C with servlets/jsps/etc. or write a servlet/jsp/etc. layer at D using EJB layer C. </quote> Well, this isn't very odd! It resembles the way we (and probably a lot Of other people) do things... <quote> The above appears VERY FLEXBILE to me. If I got you right, you would like to add security at layer A. This would screw up the model at various points (my problem - I do not have to use those security features). Furthermore, it might not be a good idea to have a depency in a Spring security API on SPECIFIC other security providing frameworks such as EJB and Servlets - relying on the Principal interface sort of introduces such a dependency, though. Please don't get me wrong: These are mainly my thoughts on how your proposal would affect my current model... </quote> I totally get your point. The way you're working is exactly the same as We do. We call layers A & B (they don't differ much here) the module layer here, the layer above is the component layer containing business logic... Modules can't have security, can't have io, can't have networking etctera (basically all EJB forbids)... The component layer contains transactions/security, etctera. The thing is, that the security model J2EE provides does not meet our demands when it comes to security for __parts of objects__. I'm trying to figure out something to add this. This does not mean I'm intruding on the module level (A+B). You can compare it a lot with the validation framework. We're having the commons validator included as validator for the Spring framework (just extend the validator interface and use the commons validator there). Each data object in our system has a validation.xml file (located right beside the class file, called [class].validation.xml). This means I haven't intruded on the data level, just added a descirptorfile, describing validation rules... No extra interface (I hate that ;-). Same thing holds for the Hibernate stuff... We're using a proprietary little farmework for integration of Hibernate into Spring (would rather have used Spring here, but the framework is already in place for a long time). The Hibernate files are placed right besides the data files and are called [class].hbm.xml. Right now I want to add security. HOW the security is done, is actually determine by the security-implementation (in this cause a RoleObjectPermissionsWhatever, __located at the component level (Spring + C)__, however using the descriptor files from the module level (A+B)... No extra interface or classes to extend, just an extra description. What the criteria for the permissions would be, is totally up to the implementation. In this case I need Role/Principal information, which means I either need the SessionContext/EntityContext or a ServletRequest (whatever, something using JAAS/javax.security). This means the implementation can __never__ be located at the modulelayer (A+B). Other implementations would provide time based permissions (between 2am-3am not possible to edit backup schedule, because backup is actually done then)... Anyway, I hope this clarifies things a little bit and I hope to get some more feedback and stuff (people just shouting __arghh this is ugly__ would do as well!!!)... Thanx, Alef ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.502 / Virus Database: 300 - Release Date: 18/07/2003 |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-08-18 20:41:57
|
Trevor, Juergen, Well, could not really answer last two weeks because of a holiday... Anyway, I've been thinking about it and I think you made a good point! The solution I am implementing will not be intrusive at all, but specifying how security is to be handled does not sound like a responsibility for the Srping framework... However, since I'm still going to implement this, indeed I need to be able to override to ServletRequestDataBinder (and I can think of other situations where this might come in handy). Basicaly it's not really possible right now since the Binder is instantiated in about 4 places in a hardcoded way. We could do it somewhat similar to the LocaleResolver, but then implementing a FactoryBean using a predefined name (of course by default the ServletRequestDataBinder will be used)?? Juergen, have you got opinions about this? Alef -----Oorspronkelijk bericht----- Van: spr...@li... [mailto:spr...@li...] Namens Trevor Cook Verzonden: Friday, August 01, 2003 4:37 PM Aan: spr...@li... Onderwerp: RE: [Springframework-developer] polishing and new features - security model?????? I think Security might be too large an issue to be addressed in Spring, at least without complicating it even further. While you're idea has promise, there are so many other ways of handling it (such as with db permissions, handling only in certain layers, creating object hierarchies with different methods) that my opinion is we should leave it. Spring's philosophy (IMO) has been about providing a generic core infrastructure that does NOT intrude on the business layer, and does not enforce a specific way of coding (for example the whole JDBC vs EJB vs Hibernate vs JDO is handled seamlessly from the perspective of the business layer). I would vote against adding the sort of handling you're describing. That being said, we have run into some of the issues you're discussing in our programming over the last few months on a Spring-based web-app. We solved our problem through custom taglibs in the (jsp) web layer (this handles accessors), and you can use a custom binder (instead of the default from BindUtils) which receives the request object (so has access to security info) before processing each object. I'm not quite up-to-speed on the current codebase, so Juergen may have a "quick-tip" on how best to override the binder used. AOP also looks very promising, although I have yet to get into it. Basically, Spring provides many ways for you to handle your problem according to your needs, but I don't think we can generalize the (security) solution, only the tools (Spring) to deal with it as needed. My 2 cents. Trevor D. Cook -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Alef Arendsen (JTeam) Sent: August 1, 2003 4:24 AM To: 'Timo Verhoeven'; spr...@li... Subject: RE: [Springframework-developer] polishing and new features - security model?????? <quote> C - [ depends on project ] B - POJO Business Objects A - POJO DAO Objects (Hibernate in my case) Objects in each layer may only call other Object in the same layer or Objects in the NEXT lower layer. Given I was to build an EJB solution, layer C would be a SINGLE session facade SLSB (single because I want to avoid COSTLY inter EJB calls). For testing/QA, I would write unittests at layer C to test B and A, and maybe unittests at layer D to test the SLSB. For maintenance (developers only) I could write another POJO java-app running at C. If I wanted to CHANGE the solution-type from EJB to webinterface I could either replace the SLSB at C with servlets/jsps/etc. or write a servlet/jsp/etc. layer at D using EJB layer C. </quote> Well, this isn't very odd! It resembles the way we (and probably a lot Of other people) do things... <quote> The above appears VERY FLEXBILE to me. If I got you right, you would like to add security at layer A. This would screw up the model at various points (my problem - I do not have to use those security features). Furthermore, it might not be a good idea to have a depency in a Spring security API on SPECIFIC other security providing frameworks such as EJB and Servlets - relying on the Principal interface sort of introduces such a dependency, though. Please don't get me wrong: These are mainly my thoughts on how your proposal would affect my current model... </quote> I totally get your point. The way you're working is exactly the same as We do. We call layers A & B (they don't differ much here) the module layer here, the layer above is the component layer containing business logic... Modules can't have security, can't have io, can't have networking etctera (basically all EJB forbids)... The component layer contains transactions/security, etctera. The thing is, that the security model J2EE provides does not meet our demands when it comes to security for __parts of objects__. I'm trying to figure out something to add this. This does not mean I'm intruding on the module level (A+B). You can compare it a lot with the validation framework. We're having the commons validator included as validator for the Spring framework (just extend the validator interface and use the commons validator there). Each data object in our system has a validation.xml file (located right beside the class file, called [class].validation.xml). This means I haven't intruded on the data level, just added a descirptorfile, describing validation rules... No extra interface (I hate that ;-). Same thing holds for the Hibernate stuff... We're using a proprietary little farmework for integration of Hibernate into Spring (would rather have used Spring here, but the framework is already in place for a long time). The Hibernate files are placed right besides the data files and are called [class].hbm.xml. Right now I want to add security. HOW the security is done, is actually determine by the security-implementation (in this cause a RoleObjectPermissionsWhatever, __located at the component level (Spring + C)__, however using the descriptor files from the module level (A+B)... No extra interface or classes to extend, just an extra description. What the criteria for the permissions would be, is totally up to the implementation. In this case I need Role/Principal information, which means I either need the SessionContext/EntityContext or a ServletRequest (whatever, something using JAAS/javax.security). This means the implementation can __never__ be located at the modulelayer (A+B). Other implementations would provide time based permissions (between 2am-3am not possible to edit backup schedule, because backup is actually done then)... Anyway, I hope this clarifies things a little bit and I hope to get some more feedback and stuff (people just shouting __arghh this is ugly__ would do as well!!!)... Thanx, Alef ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.502 / Virus Database: 300 - Release Date: 18/07/2003 ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Rod J. <rod...@in...> - 2003-07-31 22:46:58
|
> application context includes via XML entities: the new ResourceBaseEntityResolver resolves such entities relative to the resource base of the application context now, allowing for splitting context definitions into multiple files; Excellent. > DAO base classes: the new JdbcDaoSupport, HibernateDaoSupport, and JdoDaoSupport classes in respective support packages can serve as convenient base classes for DAOs that use the templates; Also excellent. This is an important selling point for Spring, as the Hibernate forum shows. Regards, Rod |
