Request to reserve two hidden field names

[Robert Leland <Ro...@freetocreate.org>]

Over the last week in beginning to work with struts I have found
myself creating hidden fields to pass information on which button
the user has clicked. Then taking alternative "forwarding" actions
in the associated Action class.

So I have been doing:
<struts:input type="submit" value="Button1"
  onClick="document.menu.cmd.value='button1'">
<struts:input type="submit" value="Button2"
   onClick="document.menu.cmd.value='button2'">

I would like to propose a convention of reserving two hidden field names:
"cmd" and "token" as a --first-- step to providing an supplimental/alternative
method
of dispatching commands. That way if and when I can cleanly fit
this method into struts it would be available to all.

"cmd" would be the hidden field name to store commands.
"token" would be hidden field to store tokens for commands
            that need to assure transaction integrity which should
            only be performed once. A token can be used only once,
            and is destroyed after its use.

The ultimate goal is to present the user a non changing URL,
provide for transaction integrity when needed,
and provide a standard method for handling multiple commands from
a menu of choices:

PLEASE LET ME KNOW IF STRUTS ALREADY DOES THIS,
as I don't want to reinvent the wheel !!!

The page form tag would ultimetely look like:
<struts:form name="menu" action="application.do" >

For now I plan on staying completely inside the struts framework,
I have a deadline Oct 16. So my apps won't have the common URL
but will have the other attributes and so I use a unique name for each form.

I am providing for the alternate commands inside each page's associated
Action class, probably like everyone else.
Then using the mapping.findForward(cmd) to find the next action.

FYI I am basing my idea's on the techniques presented in
"Web Development with Java Server Pages"

Comments ?

-Rob

Re: Request to reserve two hidden field names

[Robert Leland <Ro...@freetocreate.org>]

It's going to take me a while to digest what you have said since I am
new at this. So for now I won't reply to all you have said.

> Class attribute:
> * You need to keep the state of the form in a multiple state form. That way,
> you can disable the [Back] button of the browser.

Personally, I would want to always do this for just that reason. Then w/o
rewriting
the URL with request parameters how can the HTML convey what actions the
user has taken without using the use of hidden fields ?
In the case of values the user has selected on the same form the values would be

reflected in the ActionForm class. So I don't see the distinction between
Class attributes and hidden fields.

I am thinking in terms of DATA and CONTROL information. Buttons which trigger
a submit are CONTROL information. The DATA can also determine what actions
are taken but not by the dispatch mechnism in struts.


> The action hidden field is so commonly used that it could be integrated in
> the ActionForm class, with the get/set functions.

This would be a good thing to do in a version 1.1 of struts. This was one
advantage of having the ActionForm as a Interface, though I can add that
via Inheritance.

> Just a few ideas...Pierre Métras

Thanks !!!

Rob

Re: Request to reserve two hidden field names

[Pierre Métras <ge...@sympatico.ca>]

Taylor wote:

> Just glancing at the example application bundled with struts I found this:
>
> <struts:hidden property="action"/>
>
> In other cases the "action" is sent as a request parameter in the URL.
> So even the example of how to use struts, which is basically all newbies
> have to go on, uses a hidden field to pass info back to the servlet.  Just
> simply having two instance variables 'cmd' and 'token' doesn't solve the
> problem of informing server side objects about which button or link the
user
> selected.

Let's sort when it's more natural to use hidden fields against class
variables.

Hidden field:
* You want to be able to see the value stored in the field (use your browser
to show the source), for instance for debug (but in that case, it's safer to
write a special page to show all the session attributes...).
* You want to send the content of the field with the other fields of a form.
This is justified if you use graphical buttons instead of the classical
Submit and Cancel. You need to fill the field in JavaScript before
submitting the page.
* You're an ol' HTML chap, and you still think that mixed <TABLE> and <FONT>
tags are better than style sheets. And you can remind that your first HTML
form already had hidden fields...;-)
* You are managing the state of your form on the client side, with
JavaScript.
* In a GET action, because Struts uses logical forwards, it's simpler to put
URL parameters in a field than to append parameters to the links.

Class attribute:
* You need to keep the state of the form in a multiple state form. That way,
you can disable the [Back] button of the browser.
* You want to freeze a common behaviour in a Java class instead of spreading
fields in all your forms.
* You don't want to use a <FORM>?


In fact, generally, the two approaches are complementary. For instance, in a
form with two select boxes (to chose a car and a color), we could have the
following state graph:

    Init --->
        Select a car ---->
            Select a color ---->
                Display the reference number

You use a class attribute to store the static state of the form, and an
hidden "action" field to store the dynamic action of the user in the form
(select an item in one or the other select box).

Open the form
    state="Init"
The user selects a car model in the first select box (action="select1")
    state="CarSelected"
The user selects a color for the car (action="select2")
    state="ColorSelected"
Display the reference
    state="DisplayReference"

You can decide that you don't allow the user to change the car selected but
only the color, or reinit the color tables when he changes the car... Of
course, this sends a request to the server to update the state of the form.
This kind of model is also used with "wizard style" forms.

The action hidden field is so commonly used that it could be integrated in
the ActionForm class, with the get/set functions.
The state field don't need to be presented to the user and should be
integrated in an ActionStateForm class, inheriting from ActionForm. There
would be a changeState(action) function that would be able to change the
state of the form, and then you could proceed to the validate() function.

Just a few ideas...

Pierre Métras

Re: Request to reserve two hidden field names

[Robert Leland <Ro...@freetocreate.org>]

> Just glancing at the example application bundled with struts I found this:
>
> <struts:hidden property="action"/>
>

Thanks for pointing this out.

> simply having two instance variables 'cmd' and 'token' doesn't solve the
> problem of informing server side objects about which button or link the user

I am not following you on this,I need to go back and look
through the struts code more to fully understand.
The 'cmd' would act as the request parameter and the URL.
So what is the difference between 'URL?option1' and
the string 'URL1.option1' ? Don't they both contain the same information ?

-Rob

> Taylor

Re: Request to reserve two hidden field names

[Taylor Cowan <ta...@bondisoftware.com>]

> Just a question: why use hidden fields instead of having a class MenuForm
> derived class ActionForm, with two instance variables 'cmd' and 'token'?

Just glancing at the example application bundled with struts I found this:

<struts:hidden property="action"/>

In other cases the "action" is sent as a request parameter in the URL.
So even the example of how to use struts, which is basically all newbies
have to go on, uses a hidden field to pass info back to the servlet.  Just
simply having two instance variables 'cmd' and 'token' doesn't solve the
problem of informing server side objects about which button or link the user
selected.

Taylor

----- Original Message -----
From: "Pierre Métras" <ge...@sympatico.ca>
To: <st...@jakarta.apache.org>
Sent: Tuesday, October 03, 2000 10:31 AM
Subject: Re: Request to reserve two hidden field names


> Robert wrote:
>
> > Over the last week in beginning to work with struts I have found
> > myself creating hidden fields to pass information on which button
> > the user has clicked. Then taking alternative "forwarding" actions
> > in the associated Action class.
> >
> > ...
> >
> > I would like to propose a convention of reserving two hidden field
names:
> > "cmd" and "token" as a --first-- step to providing an
> supplimental/alternative
> > method
> > of dispatching commands. That way if and when I can cleanly fit
> > this method into struts it would be available to all.
> >
> > "cmd" would be the hidden field name to store commands.
> > "token" would be hidden field to store tokens for commands
> >             that need to assure transaction integrity which should
> >             only be performed once. A token can be used only once,
> >             and is destroyed after its use.
> >
>
> Just a question: why use hidden fields instead of having a class MenuForm
> derived class ActionForm, with two instance variables 'cmd' and 'token'?
>
> With hidden fields, a malicious user could see their content and change
the
> value of a field and resubmit a transaction. The only advantage I can see
is
> if you need to change their value with JavaScript code on the browser
side,
> without a round-up to the server.
> If you use your own class, you don't need any more to reserve field names.
> And you can add your menu behaviour without changing your JSP code: just
> change your inheritance link in the form bean associated with the page, et
> voilà!
>
> Pierre Métras

Re: Request to reserve two hidden field names

[Robert Leland <Ro...@freetocreate.org>]

>
> Just a question: why use hidden fields instead of having a class MenuForm
> derived class ActionForm, with two instance variables 'cmd' and 'token'?

Actually the hidden fields are in the MenuForm class as you suggest.
And uses struts to load and unload them

> With hidden fields, a malicious user could see their content and change the
> value of a field and resubmit a transaction.

I wasn't aware of that. However, the token would prevent some
malicious actions.

The Token is a hashed string encoded via MD5 or blowfish etc
             that contains the unique session ID and current system time
             or what evey else you wish to include.
             Altering its contents would be pointless. If it were altered
             then the command sent would be ignored.

The servlet knows what the current valid token is
and a token can be used once and only once.
Once a token has been submitted, the current valid token is destroyed.
Resubmitting it would result in the command being ignored
or redisplaying the current page or what ever action you wished to take.


> The only advantage I can see is
> if you need to change their value with JavaScript code on the browser side,
> without a round-up to the server.

Yep

> If you use your own class, you don't need any more to reserve field names.
> And you can add your menu behaviour without changing your JSP code: just
> change your inheritance link in the form bean associated with the page, et
> voilà!

As an alternative I have also used :
<struts:input type="submit" value="Button1"
    onMouseover="document.menu.action='button1' " >

Which doesn't use a hidden field for 'cmd'. This infact ties in better with
struts dispatching mechanism.

> Pierre Métras

-Rob

Re: Request to reserve two hidden field names

[Pierre Métras <ge...@sympatico.ca>]

Robert wrote:

> Over the last week in beginning to work with struts I have found
> myself creating hidden fields to pass information on which button
> the user has clicked. Then taking alternative "forwarding" actions
> in the associated Action class.
>
> ...
>
> I would like to propose a convention of reserving two hidden field names:
> "cmd" and "token" as a --first-- step to providing an
supplimental/alternative
> method
> of dispatching commands. That way if and when I can cleanly fit
> this method into struts it would be available to all.
>
> "cmd" would be the hidden field name to store commands.
> "token" would be hidden field to store tokens for commands
>             that need to assure transaction integrity which should
>             only be performed once. A token can be used only once,
>             and is destroyed after its use.
>

Just a question: why use hidden fields instead of having a class MenuForm
derived class ActionForm, with two instance variables 'cmd' and 'token'?

With hidden fields, a malicious user could see their content and change the
value of a field and resubmit a transaction. The only advantage I can see is
if you need to change their value with JavaScript code on the browser side,
without a round-up to the server.
If you use your own class, you don't need any more to reserve field names.
And you can add your menu behaviour without changing your JSP code: just
change your inheritance link in the form bean associated with the page, et
voilà!

Pierre Métras