Menu
▾
▴
RE: [Springframework-developer] Overriding ServletRequestDataBinder (WAS: polishing and new features - security model??)
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-08-20 11:56:33
|
Juergen,
Ok, there we go...
There are three use cases.
*** Security
Suppose I want to be able to hide or show certain fields in a form based =
on credentials of a user. Using a handlerinterceptor I will be able to =
inspect the beans for the view and construct information for the view to =
do or do not render certain fields. However, I have to retrieve the =
information while rendering the view. Using the spring:bind tag I can =
retrieve information about what field I'm rendering, but then I still =
have to retrieve the security information for this specific field. The =
ServletRequestDataBinder (SRDB) has all information about the object it =
is created for and would then also be the place to implement security in =
my opinion (at least, in an extending class). Since the SRDB is also =
reachable from the spring:bind tag (and also from inside nested tags) I =
would create a tag retrieving the Errors object (=3D SRDB) which in this =
case also can also generate security information about the field I have =
to render (or not)... I don't want to have the information embedded in =
my model, since I don't consider it to be model-information (just as =
validation information isn't).
*** ListDataBinder
Suppose I want render a List of command objects, instead of a single =
object and still be able to use the spring:bind things. Right now, I've =
got a ListDataBinder (extending ServletRequestDataBinder) that =
implements Collection in order to be able to iterate through it in the =
view. In JSPs this enables me to render a list of object using the =
spring:bind tag (see code snippet 1).
*** DataBinder using different formats
One of our (web)interfaces uses XML at the client side to retrieve and =
post data. The XML has to be transformed to objects, just as would have =
to be done when using request params. However, I want to do this using a =
SRDB as well, to make things more consistent. Specifying which =
databinder to use would be very handy here...
I know, it's all quite complicated behavior, but it's very handy...
If you're interested but not convinced I can go more into detail...
I can imagine something like codesnippet 2 for realizing the behavior.
Alef
******** SNIPPET 1
<%-- render the names of all Accounts contained by the items var =
--%>
<c:forEach items=3D"${items}" var=3D"item" varStatus=3D"index">
<spring:bind path=3D"Account.name">
<c:out value=3D"${status.value}">
</spring:bind>
</c:forEach>
******** SNIPPET 2
<!-- this is the listController we're using -->
<bean id=3D"accountListController" =
class=3D"jteam.site.web.util.ListController">
<!-- specify databinder using a property, defaults to SRDB -->
<property name=3D"dataBinder">
<value><ref bean=3D"listDataBinder"/>
</property>
<property name=3D"listView">
<value>accountList</value>
</property>
<property name=3D"columns">
<list>
<value>accountNo</value>
<value>companyName</value>
<value>companyAddress.city</value>
</list>
</property>
</bean>
=20
<!-- databinder knowing whether or not to show certain fields for =
the requesting user -->
<bean id=3D"editAccountController" =
class=3D"jteam.site.web.util.EditAccountController">
<property name=3D"dataBinder">
<value><ref bean=3D"securityDatabinder"/>
</property>
<property name=3D"formView">
<value>addAccount</value>
</property>
....
<property name=3D"validator"><ref =
bean=3D"recordValidator"></ref></property>
</bean>
-----Oorspronkelijk bericht-----
Van: spr...@li... =
[mailto:spr...@li...] Namens =
j=C3=BCrgen h=C3=B6ller [werk3AT]
Verzonden: Monday, August 18, 2003 11:05 PM
Aan: al...@jt...; spr...@li...
Onderwerp: Re: [Springframework-developer] Overriding =
ServletRequestDataBinder (WAS: polishing and new features - security =
model??)
Alef,
=20
Just to get the idea: What do you intend to add to =
ServletRequestDataBinder via subclassing? Access control to specific =
fields of command or form beans? I'm not sure if the binder is the right =
place to do such a thing.
=20
For access control at the controller level, you could use a custom =
HandlerInterceptor implementation, to be registered with your =
HandlerMapping. Every request mapped there gets passed to the =
interceptor first then, which is able to abort the handler chain and so =
some custom security failure processing.
=20
I'm curious :-)
=20
Juergen
=20
=20
-----Urspr=C3=BCngliche Nachricht-----=20
Von: Alef Arendsen (JTeam) [mailto:al...@jt...]=20
Gesendet: Mo 18.08.2003 22:42=20
An: spr...@li...=20
Cc:=20
Betreff: [Springframework-developer] Overriding =
ServletRequestDataBinder (WAS: polishing and new features - security =
model??)
=09
=09
Trevor, Juergen,
=09
Well, could not really answer last two weeks because of a holiday...
=09
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...
=09
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.
=09
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)??
=09
Juergen, have you got opinions about this?
=09
Alef
=09
-----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??????
=09
=09
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.
=09
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.
=09
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.
=09
My 2 cents.
=09
Trevor D. Cook
=09
=09
-----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??????
=09
=09
<quote>
C - [ depends on project ]
B - POJO Business Objects
A - POJO DAO Objects (Hibernate in my case)
=09
Objects in each layer may only call other Object in the same layer or
Objects in the NEXT lower layer.
=09
Given I was to build an EJB solution, layer C would be a SINGLE =
session
=09
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
=09
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...
=09
<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.
=09
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.
=09
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.
=09
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.
=09
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)...
=09
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!!!)...
=09
Thanx,
=09
Alef
=09
=09
=09
-------------------------------------------------------
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
=09
---
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
=09
=09
=09
-------------------------------------------------------
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
=09
=09
=09
-------------------------------------------------------
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
=09
NHzn=C8=B44i=11xjjz=0Ez=C9=AE\JNr =D3=BD Jjzqzm=D8=B6?X (=1E~zw X =
b=CB=9D? jg=EB=B0=A2=1Dz=ED=BD=96=ED=B2=97
|
