I generally like to do re-fetching before saving with the Preparable interface from Struts 2. This is how things are done with UserAction. However, we still key off the id, so it has to be hidden in your form.
I do think we should change to use re-fetch by default so if you'd like to enter a bug for this, please feel free. I know how to do it with Struts 2 and Spring MVC, but don't know if it's possible with JSF and Tapestry. Matt On 3/9/07, wnqq <[EMAIL PROTECTED]> wrote:
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]
-- http://raibledesigns.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
