After reading the suggestions, I am going to go with two different actions for setting up the form. In order to use container managed security most effectively, I am going to prefix paths with admin restrictions with admin/ for ease of filter matching.
So
/EditAccount
/admin/EditAccount?user=username
Then I will make a common abstract Action class for editing an account which both actions will extend to make use of the common routines. The /EditAccount will not listen to any query params but rather use the current session data as the data to populate the form with, whereas the /admin/EditAccount will use the user parameter to lookup the user using the DeskPhone as suggested. This way, all the security is controlled by the container, but the logic is left in the action for simply setting it up as instructed (with no checks for security).
Thanks for the input and append anywhere I have deviated from the suggestion.
Dan
Looks like a good solution to me. I agree that it is best to keep all of the security policies declaratively defined. I also like to keep the link between the logged in user and his/her account "automatic" (i.e., determined by the system and looked up as close as possible to the model updates) whenever possible. Your solution does both of these things.
Note, btw, that I did not mean to recommend "desk phone" as a generic identifier. Obviously, a) the "lookup" key best for your admins to use depends on your application and b) whatever you use, it has to be unique. The app that I took the example from enforces this.
Phil
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
