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 |
On Mar 15, 2009, at 11:30 AM, David E Jones wrote: > 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. Why replace all of hyperlink fields? I think that links which don't involve passing of secure parameters (like going to a detail page from a list) may stay as they are and be rendered as anchors. Bilgin |
Administrator
|
BTW, I have opened an issue for that https://issues.apache.org/jira/browse/OFBIZ-2243
Nothing commited yet Jacques From: "Bilgin Ibryam" <[hidden email]> > > On Mar 15, 2009, at 11:30 AM, David E Jones wrote: > >> 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. > > Why replace all of hyperlink fields? I think that links which don't > involve passing of secure parameters (like going to a detail page > from a list) may stay as they are and be rendered as anchors. > > Bilgin |
In reply to this post by Bilgin Ibryam
On Mar 17, 2009, at 5:59 AM, Bilgin Ibryam wrote: > > On Mar 15, 2009, at 11:30 AM, David E Jones wrote: > >> 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. > > Why replace all of hyperlink fields? I think that links which don't > involve passing of secure parameters (like going to a detail page > from a list) may stay as they are and be rendered as anchors. Please see the rest of my comments, and more specifically the work I've actually done for this (including the ProductForms.xml file). I've described this distinction in pretty good detail. -David |
On Mar 17, 2009, at 6:36 PM, David E Jones wrote: > > On Mar 17, 2009, at 5:59 AM, Bilgin Ibryam wrote: > >> >> On Mar 15, 2009, at 11:30 AM, David E Jones wrote: >> >>> 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. >> >> Why replace all of hyperlink fields? I think that links which don't >> involve passing of secure parameters (like going to a detail page >> from a list) may stay as they are and be rendered as anchors. > > Please see the rest of my comments, and more specifically the work > I've actually done for this (including the ProductForms.xml file). > I've described this distinction in pretty good detail. > > -David > David, Yes, I read all your comments, but then I saw OFBIZ-2243 and also your last email where you said "all of the hyperlink fields need to be update". That's why decided to ask again. Now it is clear, sorry for that. Jacques, It seems that we should replace only links which call services, and this should be checked manually by following each request :( At least their number will be less than 700 as you found for in first case. Bilgin |
Administrator
|
From: "Bilgin Ibryam" <[hidden email]>
> Jacques, > It seems that we should replace only links which call services, and > this should be checked manually by following each request :( > At least their number will be less than 700 as you found for in first > case. > > Bilgin Hi Bilgin, Please, see my answer (actually David's ;o) at https://issues.apache.org/jira/browse/OFBIZ-2243?focusedCommentId=12682792&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12682792 Jacques |
Free forum by Nabble | Edit this page |