forms, security,read only fields,autopopulation

[John Rothfield <jo...@sfhypnosis.com>]

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



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: forms, security,read only fields,autopopulation

[Phil Steitz <ph...@steitz.com>]

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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>