Re: Tapestry integration

From: Robert Zeigler (robert..uregumption.com)
Date: Thu Nov 10 2005 - 12:50:08 EST

  • Next message: Cris Daniluk: "Re: Tapestry integration"

    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:50:14 EST