New Flat Grey default?

[Jacques Le Roux]

Hi,

As it's the sole theme handling RTL languages, I think we should make the New Flat Grey as default. It will also help to find issues
(if any ;o)

Jacques

[Tim Ruppert]

-1 - the Tomahawk theme has been awesome - no real to mess with it IMO.

Cheers,
Ruppert

On Jan 18, 2011, at 3:39 AM, Jacques Le Roux wrote:

> Hi,
>
> As it's the sole theme handling RTL languages, I think we should make the New Flat Grey as default. It will also help to find issues (if any ;o)
>
> Jacques
>

[Jacques Le Roux]

Yes but not for RTL languages, though I must admit we have not much supporters for RTL languages...

Jacques

From: "Tim Ruppert" <[hidden email]>

> -1 - the Tomahawk theme has been awesome - no real to mess with it IMO.
>
> Cheers,
> Ruppert
>
> On Jan 18, 2011, at 3:39 AM, Jacques Le Roux wrote:
>
>> Hi,
>>
>> As it's the sole theme handling RTL languages, I think we should make the New Flat Grey as default. It will also help to find
>> issues (if any ;o)
>>
>> Jacques
>>
>
>

[Tim Ruppert]

Just so I'm not misunderstood here - the new Flat Grey does look extremely awesome - great work everyone!

Cheers,
Ruppert

On Jan 18, 2011, at 10:06 AM, Tim Ruppert wrote:

> -1 - the Tomahawk theme has been awesome - no real to mess with it IMO.
>
> Cheers,
> Ruppert
>
> On Jan 18, 2011, at 3:39 AM, Jacques Le Roux wrote:
>
>> Hi,
>>
>> As it's the sole theme handling RTL languages, I think we should make the New Flat Grey as default. It will also help to find issues (if any ;o)
>>
>> Jacques
>>
>

[Adrian Crum]

There are more benefits than that. Flat Grey does not require
JavaScript, and it is sight-impaired accessible. It would be the most
accommodating point of entry for a new user.

-Adrian

On 1/18/2011 9:35 AM, Jacques Le Roux wrote:

> Yes but not for RTL languages, though I must admit we have not much
> supporters for RTL languages...
>
> Jacques
>
> From: "Tim Ruppert" <[hidden email]>
>> -1 - the Tomahawk theme has been awesome - no real to mess with it IMO.
>>
>> Cheers,
>> Ruppert
>>
>> On Jan 18, 2011, at 3:39 AM, Jacques Le Roux wrote:
>>
>>> Hi,
>>>
>>> As it's the sole theme handling RTL languages, I think we should make
>>> the New Flat Grey as default. It will also help to find issues (if
>>> any ;o)
>>>
>>> Jacques
>>>
>>
>>
>
>
>

[Adam Heath-2]

On 01/18/2011 11:46 AM, Adrian Crum wrote:
> There are more benefits than that. Flat Grey does not require
> JavaScript, and it is sight-impaired accessible. It would be the most
> accommodating point of entry for a new user.

Huh?  You mean all those href="javascript:submitForm()" stuff has been
removed?

[Jacques Le Roux]

From: "Adam Heath" <[hidden email]>
> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>> There are more benefits than that. Flat Grey does not require
>> JavaScript, and it is sight-impaired accessible. It would be the most
>> accommodating point of entry for a new user.
>
> Huh?  You mean all those href="javascript:submitForm()" stuff has been removed?

No, and that's the real issue... I think it will remains, except if we find another way to avoid XSS from FTL files. I don't feel it
will change...

Jacques

[Adrian Crum]

On 1/18/2011 10:08 AM, Jacques Le Roux wrote:

> From: "Adam Heath" <[hidden email]>
>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>> There are more benefits than that. Flat Grey does not require
>>> JavaScript, and it is sight-impaired accessible. It would be the most
>>> accommodating point of entry for a new user.
>>
>> Huh? You mean all those href="javascript:submitForm()" stuff has been
>> removed?
>
> No, and that's the real issue... I think it will remains, except if we
> find another way to avoid XSS from FTL files. I don't feel it will
> change...

I don't understand how changing a form's submit button to a link that
calls a submit function protects us from XSS attacks.

-Adrian

[Ryan Foster-3]

Just a point of clarification, there is still plenty of javascript throughout the framework itself, which we have been discussing at length.  The difference between Flat Grey and most of the other themes is that it does not depend on javascript for basic interaction.  The theme only loads javascript as an enhancement, where as themes like BizznessTime and Tomahawk depend on javascript for basic user interaction such as navigation and preference selection in the case of BizznessTime, and for the drop down main application navigation in Tomahawk.  I believe that was the point that Adrian was trying to make.

Ryan L. Foster
801.671.0769
[hidden email]
ryanlfoster.com

On Jan 18, 2011, at 11:08 AM, Jacques Le Roux wrote:

> From: "Adam Heath" <[hidden email]>
>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>> There are more benefits than that. Flat Grey does not require
>>> JavaScript, and it is sight-impaired accessible. It would be the most
>>> accommodating point of entry for a new user.
>>
>> Huh?  You mean all those href="javascript:submitForm()" stuff has been removed?
>
> No, and that's the real issue... I think it will remains, except if we find another way to avoid XSS from FTL files. I don't feel it will change...
>
> Jacques
>

[Adrian Crum]

Thanks Ryan! To demonstrate my point:

1. Put your mouse in a drawer.
2. Try to use OFBiz.

-Adrian

On 1/18/2011 11:14 AM, Ryan Foster wrote:

> Just a point of clarification, there is still plenty of javascript throughout the framework itself, which we have been discussing at length.  The difference between Flat Grey and most of the other themes is that it does not depend on javascript for basic interaction.  The theme only loads javascript as an enhancement, where as themes like BizznessTime and Tomahawk depend on javascript for basic user interaction such as navigation and preference selection in the case of BizznessTime, and for the drop down main application navigation in Tomahawk.  I believe that was the point that Adrian was trying to make.
>
> Ryan L. Foster
> 801.671.0769
> [hidden email]
> ryanlfoster.com
>
> On Jan 18, 2011, at 11:08 AM, Jacques Le Roux wrote:
>
>> From: "Adam Heath"<[hidden email]>
>>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>>> There are more benefits than that. Flat Grey does not require
>>>> JavaScript, and it is sight-impaired accessible. It would be the most
>>>> accommodating point of entry for a new user.
>>>
>>> Huh?  You mean all those href="javascript:submitForm()" stuff has been removed?
>>
>> No, and that's the real issue... I think it will remains, except if we find another way to avoid XSS from FTL files. I don't feel it will change...
>>
>> Jacques
>>
>
>

[Ryan Foster-3]

No misunderstanding, thanks for the compliment.  I tend to agree with you Tim.  As much as my natural human tendency would be to "toot my own horn" and show off the new theme, I don't really see a need to change the default them every time something new comes along, which has kind of been the trend lately.  Changing the default locally is quick and easy, and on the demo site, what theme is selected depends on who was using the trunk demo last so that changes all the time anyway.

Ryan L. Foster
801.671.0769
[hidden email]
ryanlfoster.com

On Jan 18, 2011, at 10:35 AM, Tim Ruppert wrote:

> Just so I'm not misunderstood here - the new Flat Grey does look extremely awesome - great work everyone!
>
> Cheers,
> Ruppert
>
> On Jan 18, 2011, at 10:06 AM, Tim Ruppert wrote:
>
>> -1 - the Tomahawk theme has been awesome - no real to mess with it IMO.
>>
>> Cheers,
>> Ruppert
>>
>> On Jan 18, 2011, at 3:39 AM, Jacques Le Roux wrote:
>>
>>> Hi,
>>>
>>> As it's the sole theme handling RTL languages, I think we should make the New Flat Grey as default. It will also help to find issues (if any ;o)
>>>
>>> Jacques
>>>
>>
>

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> On 1/18/2011 10:08 AM, Jacques Le Roux wrote:
>> From: "Adam Heath" <[hidden email]>
>>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>>> There are more benefits than that. Flat Grey does not require
>>>> JavaScript, and it is sight-impaired accessible. It would be the most
>>>> accommodating point of entry for a new user.
>>>
>>> Huh? You mean all those href="javascript:submitForm()" stuff has been
>>> removed?
>>
>> No, and that's the real issue... I think it will remains, except if we
>> find another way to avoid XSS from FTL files. I don't feel it will
>> change...
>
> I don't understand how changing a form's submit button to a link that calls a submit function protects us from XSS attacks.
>
> -Adrian

Just have a look at one of the patches at https://issues.apache.org/jira/browse/OFBIZ-2330 and you should get it

it was not forms that were changed but plain URL (get method)

The idea is before we had something like
<a href='<@ofbizUrl>request?param1=${param1Value}&param2=${param2Value}&....</@ofbizUrl>>${uiLabelMap....}</a></div></td>
So we had parameters in an URL (ie a GET type method)  and this could be exploited when the request was a Create Update or Delete
type service (no pb for Read), ie to get an access to the DB.

We have now.
<form name= "request" method= "post" action= "<@ofbizUrl>request</@ofbizUrl>">
    <input type= "hidden" name= "param1" value= "${param1Value}"/>
    <input type= "hidden" name= "param2" value= "${param2Value}"/>
    <a href='javascript:document.request.submit()'>${uiLabelMap...}</a>
</form>
As it's a POST request type method with hidden parameters included in a javascript call parameters it's not possible to use XSS
Injection (you can't hack the URL from outside to inject a script in it). Just try it if you want to be sure...

This is explained clearly at http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/XSS-Injection section "How to test
for XSS Injection vulnerabilities"

One thing I'm not quire sure though is why we use javascript calls instead of simple submit buttons (almost your question ;o). Maybe
it adds a bit of security because it's harder to inject javascript code in it (inject <script></script> tags in another
<script></script> tags couple)? But there are some cases were it's not used (CopyAgreement.ftl for instance) so I'm not sure, I
simply followed the way it was done, before I had to change one...

Of course we use ESAPI behind the scene to handle parameters encoding/decoding aspects

If you want to digg futher, have a look at https://issues.apache.org/jira/browse/OFBIZ-1525

HTH

Jacques

[Adrian Crum]

On 1/18/2011 12:56 PM, Jacques Le Roux wrote:

> From: "Adrian Crum" <[hidden email]>
>> On 1/18/2011 10:08 AM, Jacques Le Roux wrote:
>>> From: "Adam Heath" <[hidden email]>
>>>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>>>> There are more benefits than that. Flat Grey does not require
>>>>> JavaScript, and it is sight-impaired accessible. It would be the most
>>>>> accommodating point of entry for a new user.
>>>>
>>>> Huh? You mean all those href="javascript:submitForm()" stuff has been
>>>> removed?
>>>
>>> No, and that's the real issue... I think it will remains, except if we
>>> find another way to avoid XSS from FTL files. I don't feel it will
>>> change...
>>
>> I don't understand how changing a form's submit button to a link that
>> calls a submit function protects us from XSS attacks.
>>
>> -Adrian
>
> Just have a look at one of the patches at
> https://issues.apache.org/jira/browse/OFBIZ-2330 and you should get it
>
> it was not forms that were changed but plain URL (get method)
>
> The idea is before we had something like
> <a
> href='<@ofbizUrl>request?param1=${param1Value}&param2=${param2Value}&....</@ofbizUrl>>${uiLabelMap....}</a></div></td>
>
> So we had parameters in an URL (ie a GET type method) and this could be
> exploited when the request was a Create Update or Delete type service
> (no pb for Read), ie to get an access to the DB.
>
> We have now.
> <form name= "request" method= "post" action=
> "<@ofbizUrl>request</@ofbizUrl>">
> <input type= "hidden" name= "param1" value= "${param1Value}"/>
> <input type= "hidden" name= "param2" value= "${param2Value}"/>
> <a href='javascript:document.request.submit()'>${uiLabelMap...}</a>
> </form>
> As it's a POST request type method with hidden parameters included in a
> javascript call parameters it's not possible to use XSS Injection (you
> can't hack the URL from outside to inject a script in it). Just try it
> if you want to be sure...
>
> This is explained clearly at
> http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/XSS-Injection
> section "How to test for XSS Injection vulnerabilities"
>
> One thing I'm not quire sure though is why we use javascript calls
> instead of simple submit buttons (almost your question ;o).

That was EXACTLY my question.

-Adrian

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>

> On 1/18/2011 12:56 PM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <[hidden email]>
>>> On 1/18/2011 10:08 AM, Jacques Le Roux wrote:
>>>> From: "Adam Heath" <[hidden email]>
>>>>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>>>>> There are more benefits than that. Flat Grey does not require
>>>>>> JavaScript, and it is sight-impaired accessible. It would be the most
>>>>>> accommodating point of entry for a new user.
>>>>>
>>>>> Huh? You mean all those href="javascript:submitForm()" stuff has been
>>>>> removed?
>>>>
>>>> No, and that's the real issue... I think it will remains, except if we
>>>> find another way to avoid XSS from FTL files. I don't feel it will
>>>> change...
>>>
>>> I don't understand how changing a form's submit button to a link that
>>> calls a submit function protects us from XSS attacks.
>>>
>>> -Adrian
>>
>> Just have a look at one of the patches at
>> https://issues.apache.org/jira/browse/OFBIZ-2330 and you should get it
>>
>> it was not forms that were changed but plain URL (get method)
>>
>> The idea is before we had something like
>> <a
>> href='<@ofbizUrl>request?param1=${param1Value}&param2=${param2Value}&....</@ofbizUrl>>${uiLabelMap....}</a></div></td>
>>
>> So we had parameters in an URL (ie a GET type method) and this could be
>> exploited when the request was a Create Update or Delete type service
>> (no pb for Read), ie to get an access to the DB.
>>
>> We have now.
>> <form name= "request" method= "post" action=
>> "<@ofbizUrl>request</@ofbizUrl>">
>> <input type= "hidden" name= "param1" value= "${param1Value}"/>
>> <input type= "hidden" name= "param2" value= "${param2Value}"/>
>> <a href='javascript:document.request.submit()'>${uiLabelMap...}</a>
>> </form>
>> As it's a POST request type method with hidden parameters included in a
>> javascript call parameters it's not possible to use XSS Injection (you
>> can't hack the URL from outside to inject a script in it). Just try it
>> if you want to be sure...
>>
>> This is explained clearly at
>> http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/XSS-Injection
>> section "How to test for XSS Injection vulnerabilities"
>>
>> One thing I'm not quire sure though is why we use javascript calls
>> instead of simple submit buttons (almost your question ;o).
>
> That was EXACTLY my question.

Right, but most of the changes which introduced those js calls were not done on forms but plain URLs. That's why I explained it
all... For instance CopyAgreement.ftl has not been changed...
But yes, I think we could replace them by simple submit buttons. I can see not reasons why we should not.

BTW I have just tried with
deletePartyContactMechPurpose_${partyContactMechPurpose.contactMechPurposeTypeId} in
specialpurpose/ecommerce/webapp/ecommerce/customer/editcontactmech.ftl and it works well. I replaced
<!--a href='javascript:document.deletePartyContactMechPurpose_${partyContactMechPurpose.contactMechPurposeTypeId}.submit()'
class='button'>&nbsp;${uiLabelMap.CommonDelete}&nbsp;</a-->
by
<input type="submit" name="deletePartyContactMechPurpose_${partyContactMechPurpose.contactMechPurposeTypeId}" class='button'
value="&nbsp;${uiLabelMap.CommonDelete}&nbsp;"/>

any differences, any security error messages...

Maybe I miss something (XSS reinforced security?). But, like you, I can't see what! (I specifically chosen a dynamic input name)

Jacques

> -Adrian
>

[Deepak Dixit-2]

On Wednesday 19 January 2011 03:53 AM, Jacques Le Roux wrote:

> From: "Adrian Crum" <[hidden email]>
>> On 1/18/2011 12:56 PM, Jacques Le Roux wrote:
>>> From: "Adrian Crum" <[hidden email]>
>>>> On 1/18/2011 10:08 AM, Jacques Le Roux wrote:
>>>>> From: "Adam Heath" <[hidden email]>
>>>>>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>>>>>> There are more benefits than that. Flat Grey does not require
>>>>>>> JavaScript, and it is sight-impaired accessible. It would be the
>>>>>>> most
>>>>>>> accommodating point of entry for a new user.
>>>>>>
>>>>>> Huh? You mean all those href="javascript:submitForm()" stuff has
>>>>>> been
>>>>>> removed?
>>>>>
>>>>> No, and that's the real issue... I think it will remains, except
>>>>> if we
>>>>> find another way to avoid XSS from FTL files. I don't feel it will
>>>>> change...
>>>>
>>>> I don't understand how changing a form's submit button to a link that
>>>> calls a submit function protects us from XSS attacks.
>>>>
>>>> -Adrian
>>>
>>> Just have a look at one of the patches at
>>> https://issues.apache.org/jira/browse/OFBIZ-2330 and you should get it
>>>
>>> it was not forms that were changed but plain URL (get method)
>>>
>>> The idea is before we had something like
>>> <a
>>> href='<@ofbizUrl>request?param1=${param1Value}&param2=${param2Value}&....</@ofbizUrl>>${uiLabelMap....}</a></div></td>
>>>
>>>
>>> So we had parameters in an URL (ie a GET type method) and this could be
>>> exploited when the request was a Create Update or Delete type service
>>> (no pb for Read), ie to get an access to the DB.
>>>
>>> We have now.
>>> <form name= "request" method= "post" action=
>>> "<@ofbizUrl>request</@ofbizUrl>">
>>> <input type= "hidden" name= "param1" value= "${param1Value}"/>
>>> <input type= "hidden" name= "param2" value= "${param2Value}"/>
>>> <a href='javascript:document.request.submit()'>${uiLabelMap...}</a>
>>> </form>
>>> As it's a POST request type method with hidden parameters included in a
>>> javascript call parameters it's not possible to use XSS Injection (you
>>> can't hack the URL from outside to inject a script in it). Just try it
>>> if you want to be sure...
>>>
>>> This is explained clearly at
>>> http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/XSS-Injection 
>>>
>>> section "How to test for XSS Injection vulnerabilities"
>>>
>>> One thing I'm not quire sure though is why we use javascript calls
>>> instead of simple submit buttons (almost your question ;o).
>>
>> That was EXACTLY my question.
>
> Right, but most of the changes which introduced those js calls were
> not done on forms but plain URLs. That's why I explained it
> all... For instance CopyAgreement.ftl has not been changed...
> But yes, I think we could replace them by simple submit buttons. I can
> see not reasons why we should not.
>
> BTW I have just tried with
> deletePartyContactMechPurpose_${partyContactMechPurpose.contactMechPurposeTypeId}
> in
> specialpurpose/ecommerce/webapp/ecommerce/customer/editcontactmech.ftl
> and it works well. I replaced
> <!--a
> href='javascript:document.deletePartyContactMechPurpose_${partyContactMechPurpose.contactMechPurposeTypeId}.submit()'
> class='button'>&nbsp;${uiLabelMap.CommonDelete}&nbsp;</a-->
> by
> <input type="submit"
> name="deletePartyContactMechPurpose_${partyContactMechPurpose.contactMechPurposeTypeId}"
> class='button' value="&nbsp;${uiLabelMap.CommonDelete}&nbsp;"/>

IMO we can change <a href="javascript:document." call that are used for
submit a form. There is a input button of type submit that are used for
form submit.
At initial level these all form that contain <a
href="javascript:document." for  form submit are only <a tag with query
string and after security update these query string convert into form
but for form submission they changed <a to <a
href="javascript:document." instead of using input button of type submit.

We should refactor these type of unnecessary javascript call.


Thanks & Regards
--
Deepak Dixit

>
> any differences, any security error messages...
>
> Maybe I miss something (XSS reinforced security?). But, like you, I
> can't see what! (I specifically chosen a dynamic input name)
>
> Jacques
>
>> -Adrian
>>
>
>

[Scott Gray-2]

On 19/01/2011, at 10:19 AM, Adrian Crum wrote:

> On 1/18/2011 12:56 PM, Jacques Le Roux wrote:
>> From: "Adrian Crum" <[hidden email]>
>>> On 1/18/2011 10:08 AM, Jacques Le Roux wrote:
>>>> From: "Adam Heath" <[hidden email]>
>>>>> On 01/18/2011 11:46 AM, Adrian Crum wrote:
>>>>>> There are more benefits than that. Flat Grey does not require
>>>>>> JavaScript, and it is sight-impaired accessible. It would be the most
>>>>>> accommodating point of entry for a new user.
>>>>>
>>>>> Huh? You mean all those href="javascript:submitForm()" stuff has been
>>>>> removed?
>>>>
>>>> No, and that's the real issue... I think it will remains, except if we
>>>> find another way to avoid XSS from FTL files. I don't feel it will
>>>> change...
>>>
>>> I don't understand how changing a form's submit button to a link that
>>> calls a submit function protects us from XSS attacks.
>>>
>>> -Adrian
>>
>> Just have a look at one of the patches at
>> https://issues.apache.org/jira/browse/OFBIZ-2330 and you should get it
>>
>> it was not forms that were changed but plain URL (get method)
>>
>> The idea is before we had something like
>> <a
>> href='<@ofbizUrl>request?param1=${param1Value}&param2=${param2Value}&....</@ofbizUrl>>${uiLabelMap....}</a></div></td>
>>
>> So we had parameters in an URL (ie a GET type method) and this could be
>> exploited when the request was a Create Update or Delete type service
>> (no pb for Read), ie to get an access to the DB.
>>
>> We have now.
>> <form name= "request" method= "post" action=
>> "<@ofbizUrl>request</@ofbizUrl>">
>> <input type= "hidden" name= "param1" value= "${param1Value}"/>
>> <input type= "hidden" name= "param2" value= "${param2Value}"/>
>> <a href='javascript:document.request.submit()'>${uiLabelMap...}</a>
>> </form>
>> As it's a POST request type method with hidden parameters included in a
>> javascript call parameters it's not possible to use XSS Injection (you
>> can't hack the URL from outside to inject a script in it). Just try it
>> if you want to be sure...
>>
>> This is explained clearly at
>> http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/XSS-Injection
>> section "How to test for XSS Injection vulnerabilities"
>>
>> One thing I'm not quire sure though is why we use javascript calls
>> instead of simple submit buttons (almost your question ;o).
>
> That was EXACTLY my question.
>
> -Adrian

I'm not 100% sure but I think we have certain screens where it is unavoidable because the form cannot be placed where the button/link needs to reside.  An example of this might be a list with bulk action checkboxes but also row level actions.

Regards
Scott

[Adrian Crum-2]

--- On Tue, 1/18/11, Scott Gray <[hidden email]> wrote:

> On 19/01/2011, at 10:19 AM, Adrian
> Crum wrote:
>
> > On 1/18/2011 12:56 PM, Jacques Le Roux wrote:
> >> From: "Adrian Crum" <[hidden email]>
> >>> On 1/18/2011 10:08 AM, Jacques Le Roux wrote:
> >>>> From: "Adam Heath" <[hidden email]>
> >>>>> On 01/18/2011 11:46 AM, Adrian Crum
> wrote:
> >>>>>> There are more benefits than that.
> Flat Grey does not require
> >>>>>> JavaScript, and it is
> sight-impaired accessible. It would be the most
> >>>>>> accommodating point of entry for a
> new user.
> >>>>>
> >>>>> Huh? You mean all those
> href="javascript:submitForm()" stuff has been
> >>>>> removed?
> >>>>
> >>>> No, and that's the real issue... I think
> it will remains, except if we
> >>>> find another way to avoid XSS from FTL
> files. I don't feel it will
> >>>> change...
> >>>
> >>> I don't understand how changing a form's
> submit button to a link that
> >>> calls a submit function protects us from XSS
> attacks.
> >>>
> >>> -Adrian
> >>
> >> Just have a look at one of the patches at
> >> https://issues.apache.org/jira/browse/OFBIZ-2330 and
> you should get it
> >>
> >> it was not forms that were changed but plain URL
> (get method)
> >>
> >> The idea is before we had something like
> >> <a
> >>
> href='<@ofbizUrl>request?param1=${param1Value}&param2=${param2Value}&....</@ofbizUrl>>${uiLabelMap....}</a></div></td>
> >>
> >> So we had parameters in an URL (ie a GET type
> method) and this could be
> >> exploited when the request was a Create Update or
> Delete type service
> >> (no pb for Read), ie to get an access to the DB.
> >>
> >> We have now.
> >> <form name= "request" method= "post" action=
> >> "<@ofbizUrl>request</@ofbizUrl>">
> >> <input type= "hidden" name= "param1" value=
> "${param1Value}"/>
> >> <input type= "hidden" name= "param2" value=
> "${param2Value}"/>
> >> <a
> href='javascript:document.request.submit()'>${uiLabelMap...}</a>
> >> </form>
> >> As it's a POST request type method with hidden
> parameters included in a
> >> javascript call parameters it's not possible to
> use XSS Injection (you
> >> can't hack the URL from outside to inject a script
> in it). Just try it
> >> if you want to be sure...
> >>
> >> This is explained clearly at
> >> http://www.testingsecurity.com/how-to-test/injection-vulnerabilities/XSS-Injection
> >> section "How to test for XSS Injection
> vulnerabilities"
> >>
> >> One thing I'm not quire sure though is why we use
> javascript calls
> >> instead of simple submit buttons (almost your
> question ;o).
> >
> > That was EXACTLY my question.
> >
> > -Adrian
>
> I'm not 100% sure but I think we have certain screens where
> it is unavoidable because the form cannot be placed where
> the button/link needs to reside.  An example of this
> might be a list with bulk action checkboxes but also row
> level actions.
>
> Regards
> Scott

On most popular websites the bulk action link disappears with JavaScript turned off. For example, on Yahoo mail the "Check All" link disappears with JS turned off.