Dear Nathan, Matt, and Bryan, Thank you for your valuable comments. Yes, you are correct that each approach has its advantages and disadvantages.
The approach in the current tutorial uses a request-scope form and we have to put all the attributes (including id) in the page. Other options include utilizing session, as well as re-fetching the object in your Action before saving it. All of these approaches have issues: * Request-scoped: Everything has to be in the page as editable or hidden fields. If you leave a field out, it'll get set to null when you save the page. There may also be security implications with using hidden fields - so don't use this approach if you have sensitive data. ACL must be applied for this approach. However, ACL also has scalability issue: ACLs are very usefull for classes up to 500 instances. Especially the collection filtering gets very slow with a big amount of objects (>5000). ACEGI offers a caching strategy, but this does not fix the problem. * Session-scoped: You have to clean up the session after successfully saving the form. Scalability is also an issue. * Re-fetching before save: You have to figure out which fields have changed and merge the two objects together. melinate wrote: > >> For example, assuming there are total of 100 Car records in the database. >> Assuming 3 Cars belong to me, and I am allowed to do a filtered search >> (select from car where owner = 'myname') and then edit the returned list. >> Practically, I should not be able to edit the other 97 Cars. However, I >> can >> simply access url=/editCar.html?id=99 and then change the owner of Car >> (id=99) to be myself. So I can easily get one more car without paying any >> money. :) >> >> That's the security issue I was talking about. >> >> There are several ways to prevent it: >> (1) one is storing id in the session instead of showing it on the web >> page. >> > I agree with Matt that this is not a scalable solution in many > situations. What happens when a user can edit 1,000 objects, and you > have 1,000 users? 10,000 & 10,000? etc. >> (2) another one is implementing an authorization mechanism which is >> similar >> to what is applied to User. >> > User is an example of a good security implementation within AppFuse. Of > course there are other ways, but this is the best that we have come up > with. >> (3) etc >> > What do you think? > Nathan > > -- View this message in context: http://www.nabble.com/hide-id-of-person-from-the-web-pages-tf3376792s2369.html#a9401749 Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
