I just release Dreamsource ORM 2.0. It can solve your problems. You can download it from http://dreamsource-orm.googlecode.com/files/dreamsource2_0_0_04062009_GWT_src.jar.
Jim On Apr 5, 10:39 pm, M Shannon <[email protected]> wrote: > Hi All, > > I have a database-backed data model for my application in third normal > form. > > e.g > > USER table: > -------------------- > ID > NAME > > ORDER table: > -------------------- > ID > USER_ID > > ORDER_LINE table: > -------------------- > ID > ORDER_ID > DESCRIPTION > AMOUNT > CUSTOM_FIELD > > I'm intending on user dozer to map from my server entities to > appropriate data transfer objects that will be rendered and partially > editable from the gwt based client. > > My main concern is a black-hat client forging bogus but valid requests > that could result in update of an object that should not have been > appropriate. > For example, imagine if I allowed an end-user to edit CUSTOM_FIELD in > the ORDER_LINE table above and supply an appropriate value. > > The user submit some ORDER_LINE object instance over the wire, but has > intentionally fraudulently manipulated the ID/ORDER_ID value to some > other user's ORDER. On the server-side if I am to take the submitted > data at face value, I end up modifying some other person's object. > > Obviously there are techniques I could apply on the server-side to > reduce the risk, for example looking up the supposed ORDER_LINE and > tracing back to see if its associated with the USER whom is connected > in the server-session. What I'm concerned about, is with a massive > heavily normalized data model the cost associated with this. If i'm > having to lookup every object along the chain to get back to the USER, > this will take up numerous CPU cycles and could result in significant > database IO (if non-cached objects in middle tier etc) etc. > > I'm wondering how other users of GWT have overcome this issue - what > techniques / design patterns etc they may have used to solve the > problem. > > If i were to supply to the client for each row object, some encrypted > or hashed value that would verify the row object ID was associated > with the connected USER_ID, and then require this value be returned to > the server on any update request, I would at least be able to discern > with reasonable probability that the ID has not been tampered with. > > Just looking at DOZER, it appears to support one-way mappings which > would seem to come in handy in allowing the server to return a mass of > data to client for rendering information purposes, but ignore data > submitted back from client in certain one-way only fields. The custom > converter and event listener feature it would appear could also be > leveraged to add custom verification/security logic as well. > > I notice gwt honors the transient keyword to prevent transfer of the > field via RPC - I'm wondering if this could be adapted to be a one-way > only thing. Such that server to client ok, client-server prevented. > > Sorry for the rambling post. > > All ideas appreciated. > > thanks > > Matt. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
