This is a big problem in WebWork as well - its just a reality of
bringing the domain objects closer to the browser. There are two real
issues:
- protecting objects from direct web access
-protecting properties of those objects from direct web access
I think both problems are most easily solved using annotations. Not
sure if you can use them in your environment or not, but I've stood up
a few simple implementations of annotation-based security in WebWork,
and I know that the hooks in Tapestry are very similar. In fact, both
frameworks are working on native implementations of this.
On 11/10/05, Robert Zeigler <robert..uregumption.com> wrote:
> I hear you on that one. My apps always check to ensure a user
> has legitimate access to an object before doing anything with that
> object. But... that can be a pain, as you pointed out.
> So, ways to prevent tampering...
> 1) Tweak the squeeze adapter to be aware of security constraints.
> You could presumably add some sort of Security manager
> into which you could pass the "inflated" object.
> This is a nice approach in that it centralizes the logic for your
> security constraints. Your security manager would need some way to get
> access to the current user... (eg: using the threadlocal trick for your
> engine so you can get at the visit...) I'm a little unsure, however, on
> what should happen should a user /not/ have permission for a particular
> object. If you throw an exception, where's it going to propagate to? Is
> there any chance to catch it some place reasonable and redirect to a
> sort of "permission denied" page or some such? I don't have immediate
> answers to that question. You could, of course, change your error page
> to be a generic error page (instead of the tapestry one), and not worry
> about it... throw your exception, user gets reasonable error page...
> everyone is happy?
>
> In general, /any/ approach centered around the squeeze adapter is going
> to have that same issue... so you detect url tampering; /then/ what?
> Other squeezer-centric methods might be to tweak the adapter to also
> write the object hashcode into the url (or some other sort of object
> "checksum"). Even if a user tweaks the id, they won't be able to change
> the checksum to match. If enough people like this idea, I could write
> it into the existing squeeze adapter (again, with the caveat of: now what?).
>
> An option (at least for direct links, see below) for doing this in the
> page while limiting redundant code, might be to have every page extend a
> "validator" page or some such, that has a method
> "validateObjects(Object[] params)"; in your listeners, you can pass in
> your object[] array, etc. This would also work for external links; put
> the call inside of the activate method (or whatever it's called; I
> always forget. :)
>
> This approach isn't going to work so well for, eg, form hidden fields,
> but those are "re-inflated" during rewind, before your listener, and you
> don't have any single method that you can use for all parameters. That
> is, imagine something like the following:
> You store an object at the top of the form which contains a
> user-specific object being edited. If a user tampered with the "value"
> of the hidden field, your form would be rewound, inflating the
> (tampered) object, and also /updating/ the tampered object, all before
> you had a chance to do anything. There is, however, something of a
> solution here, as well, b/c the hidden component allows a listener; you
> could write a single listener which ties into your validateObjects
> method, and then just use that listener on all your forms.
>
> I feel like I wrote a lot and said very little, sorry. But this is
> definitely an area of thought for me, and I'm open to suggestions on
> ways to tweak the squeezer to make urls "tamper-proof" /and/ have some
> sort of sensible behavior for when urls have been tampered with.
>
> Robert
>
> Gentry, Michael (Contractor) wrote:
>
> >[Maybe I should put this on the Tapestry list, but since it started here
> >...]
> >
> >OK Robert, I'm thinking about DirectLink now, especially since the T4
> >docs say that ActionLink is deprecated. :-(
> >
> >Suppose I did a Cayenne DataSqueezer for Tapestry and then did your
> >example of a DirectLink using:
> >
> > parameter="ognl:someDataObject"
> >
> >Which generates an URL with something like:
> >
> > sp=Pnt/DataObject/300
> >
> >How do you prevent a user from changing that URL to have a 301 or a 302
> >or whatever? It is quite trivial to copy the link's URL, paste it in
> >the browser address line, and edit it. Record 301 could contain
> >personal information for a different person that shouldn't be vended to
> >the person receiving the link with 300 in it. It seems like I'm going
> >to have to do a lot more defensive programming without ActionLink.
> >
> >Thoughts on that? I'm curious if you've already solved the malicious
> >user problem! :-)
> >
> >Thanks!
> >
> >/dev/mrg
> >
> >
> >
>
>
This archive was generated by hypermail 2.0.0 : Thu Nov 10 2005 - 12:55:25 EST