John Rothfield wrote: >I have an account information screen that lets the user change their >address. The screen displays account # also, but account # is a read only >field. >Question: should account # be in the form bean? I need to populate account >#, but >I'm afraid the user will hack the form and add an accountNo input field >which would then >automatically set the accountNo field. > >One approach is to have the form object contain the model as a variable, >and to have a >"get" method but no "set" method. > >The example that came with struts uses the following: > > <bean:write name="user" property="username" filter="true"/> > >where user is the formname. > >Any comments? > >Thanks, John > First, you should ask yourself whether the user needs to see the full account number. You might want to consider displaying a masked version, showing only enough to distinguish between multiple accounts that a user may have (e.g. xxx-xxxx-1234).
Second, and most importantly, you need to maintain the separation of the model and the view. Security is one of the primary motivators for Model II/MVC. Updates to the model should be handled by business objects, not form beans or even action classes. Finally, the mapping between accounts and logged in users should if possible be maintained by the security system. If you are using container-managed security, you can get the identity of the logged-on user using J2EE APIs in either the web container or the EJB container. Before making any model updates, you should verify that the logged in user actually owns the associated account, using the J2EE (or application) APIs to get the identity of the user and either your durable security store or a session object that is not bound to the view, loaded at login, read-only thereafter, to do the check. The closer you do the account authorization check to the actual model update, the better. If you choose not to implement account-level authorization control in your business objects, you should certainly avoid exposing the "session account data of record" in your form beans. You can still present the data; but the form bean getter() should just access the *real* session data and the setter() should be limited to setting an index into the *real* list of accounts for the user stored elsewhere in the session. This is the main point -- the set of accounts associated with a logged in user should in no case (other than account enrollment) be modifiable by the user. Just my -- admitedly conservative -- opinion. Phil Steitz > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
