More Security: Hidden forms instead of links in the form widget

[David E Jones]

I have implemented an improvement to the form widget (still needs  
introduction in other places in the form and other widgets).

For an example see the UpdateProductPrice form in the ProductForms.xml  
file, namely the deleteLink field which now looks like this:

        <field name="deleteLink" title=" " widget-style="buttontext">
            <hyperlink target="deleteProductPrice" description="$ 
{uiLabelMap.CommonDelete}" link-type="hidden-form" also-hidden="false">
                <parameter param-name="productId"/>
                <parameter param-name="productPriceTypeId"/>
                <parameter param-name="productPricePurposeId"/>
                <parameter param-name="currencyUomId"/>
                <parameter param-name="productStoreGroupId"/>
                <parameter param-name="fromDate"/>
            </hyperlink>
        </field>

There are 2 changes to note here:

1. the new attribute "link-type" is using the new option value "hidden- 
form" so that it will be rendered as a hidden form instead of as a  
typical anchor (ie "<a href...")

2. there is a sub-element to hyperlink called "parameter" that splits  
out the individual parameters instead of having them all embedded in  
the hyperlink -> target attribute, which now just has the request name  
(you can still put parameters, etc there, but they will NOT be put  
into hidden form fields unless they use the parameter tag)

In short all of the hyperlink fields need to be updated with these two  
changes. As soon as the framework is extended so that this is  
supported for the sub-hyperlink element in the form widget and the  
hyperlink element in the screen and menu widgets.

This is an FYI as well as a request for help in doing this. If you're  
interested, go for it... :)

BTW, the security reason for this is that parameters on a URL are NOT  
encrypted even in an https request, but form fields are encrypted.  
Right now there is only a warning, but at some point we will make this  
an error so the data is not accepted, when non-encrypted URL  
parameters are passed to a secure request... and that means all  
parameters going to secure/https requests will need to be form fields  
like this. This will help prevent request forging (and related man-in- 
the-middle attacks), snooping of sensitive data, and so on.

-David