What about adding to the context a string representation of the parameters sent to the page?

[Jacopo Cappellato]

What do you think of the following patch?

Index: framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
===================================================================
--- framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
(revision 452088)
+++ framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
(working copy)
@@ -257,6 +257,8 @@
    TaglibFactory JspTaglibs = new TaglibFactory(servletContext);
    context.put("JspTaglibs", JspTaglibs);
    context.put("requestParameters",  UtilHttp.getParameterMap(request));
+  context.put("requestParametersUrl",
UtilHttp.urlEncodeArgs(UtilHttp.getParameterMap(request)));



It basically adds an url friendly representation of the parameters
posted to a screen so that they can be appended to a link in the page in
this way:

<link target="ExampleReport?${requestParametersUrl}" text="Print this
page" style="buttontext"/>

I need something like this for example when, after submitting a find
form I get a list of records and I want to display a link to get a PDF
version of the same list: in the link I have to append the search
parameters.

Can I commit this?

Jacopo

[cjhowe]

that's a good idea.  however because you're using GET
instead of POST, you're going to end up with a 2048
character limit for the url.  Why not have an entity
that can hold larger with a single "queryId" and
simply append that?

--- Jacopo Cappellato <[hidden email]> wrote:

> What do you think of the following patch?
>
> Index:
>
framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>
===================================================================
> ---
>
framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>
> (revision 452088)
> +++
>
framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java

>
> (working copy)
> @@ -257,6 +257,8 @@
>     TaglibFactory JspTaglibs = new
> TaglibFactory(servletContext);
>     context.put("JspTaglibs", JspTaglibs);
>     context.put("requestParameters",
> UtilHttp.getParameterMap(request));
> +  context.put("requestParametersUrl",
>

UtilHttp.urlEncodeArgs(UtilHttp.getParameterMap(request)));

>
>
>
> It basically adds an url friendly representation of
> the parameters
> posted to a screen so that they can be appended to a
> link in the page in
> this way:
>
> <link target="ExampleReport?${requestParametersUrl}"
> text="Print this
> page" style="buttontext"/>
>
> I need something like this for example when, after
> submitting a find
> form I get a list of records and I want to display a
> link to get a PDF
> version of the same list: in the link I have to
> append the search
> parameters.
>
> Can I commit this?
>
> Jacopo
>

[David E Jones-2]

That's a good point Chris. There is also the problem of non-ASCII  
characters in URLs, though we could at least get around this problem  
by having it encode the characters using the \u stuff.

We could put something like this in as a nice tool, and it would be  
up to the programmer using it to determine if it is appropriate for  
whatever they are writing...

-David


On Oct 3, 2006, at 8:35 PM, Chris Howe wrote:

> that's a good idea.  however because you're using GET
> instead of POST, you're going to end up with a 2048
> character limit for the url.  Why not have an entity
> that can hold larger with a single "queryId" and
> simply append that?
>
> --- Jacopo Cappellato <[hidden email]> wrote:
>
>> What do you think of the following patch?
>>
>> Index:
>>
> framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>
> ===================================================================
>> ---
>>
> framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>
>> (revision 452088)
>> +++
>>
> framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>
>> (working copy)
>> @@ -257,6 +257,8 @@
>>     TaglibFactory JspTaglibs = new
>> TaglibFactory(servletContext);
>>     context.put("JspTaglibs", JspTaglibs);
>>     context.put("requestParameters",
>> UtilHttp.getParameterMap(request));
>> +  context.put("requestParametersUrl",
>>
> UtilHttp.urlEncodeArgs(UtilHttp.getParameterMap(request)));
>>
>>
>>
>> It basically adds an url friendly representation of
>> the parameters
>> posted to a screen so that they can be appended to a
>> link in the page in
>> this way:
>>
>> <link target="ExampleReport?${requestParametersUrl}"
>> text="Print this
>> page" style="buttontext"/>
>>
>> I need something like this for example when, after
>> submitting a find
>> form I get a list of records and I want to display a
>> link to get a PDF
>> version of the same list: in the link I have to
>> append the search
>> parameters.
>>
>> Can I commit this?
>>
>> Jacopo
>>
>

[Jacopo Cappellato]

Chris, David,

thanks for your interesting comments.
Just to be sure to understand your comments: is it ok if I commit this
stuff (even if it could not be used under some circumstances i.e. a lot
of parameters, or values containing non-ASCII characters) or should I
wait for a better solution?

Thanks,
Jacopo

David E Jones wrote:

>
> That's a good point Chris. There is also the problem of non-ASCII
> characters in URLs, though we could at least get around this problem by
> having it encode the characters using the \u stuff.
>
> We could put something like this in as a nice tool, and it would be up
> to the programmer using it to determine if it is appropriate for
> whatever they are writing...
>
> -David
>
>
> On Oct 3, 2006, at 8:35 PM, Chris Howe wrote:
>
>> that's a good idea.  however because you're using GET
>> instead of POST, you're going to end up with a 2048
>> character limit for the url.  Why not have an entity
>> that can hold larger with a single "queryId" and
>> simply append that?
>>
>> --- Jacopo Cappellato <[hidden email]> wrote:
>>
>>> What do you think of the following patch?
>>>
>>> Index:
>>>
>> framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>>
>> ===================================================================
>>> ---
>>>
>> framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>>
>>> (revision 452088)
>>> +++
>>>
>> framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
>>>
>>> (working copy)
>>> @@ -257,6 +257,8 @@
>>>     TaglibFactory JspTaglibs = new
>>> TaglibFactory(servletContext);
>>>     context.put("JspTaglibs", JspTaglibs);
>>>     context.put("requestParameters",
>>> UtilHttp.getParameterMap(request));
>>> +  context.put("requestParametersUrl",
>>>
>> UtilHttp.urlEncodeArgs(UtilHttp.getParameterMap(request)));
>>>
>>>
>>>
>>> It basically adds an url friendly representation of
>>> the parameters
>>> posted to a screen so that they can be appended to a
>>> link in the page in
>>> this way:
>>>
>>> <link target="ExampleReport?${requestParametersUrl}"
>>> text="Print this
>>> page" style="buttontext"/>
>>>
>>> I need something like this for example when, after
>>> submitting a find
>>> form I get a list of records and I want to display a
>>> link to get a PDF
>>> version of the same list: in the link I have to
>>> append the search
>>> parameters.
>>>
>>> Can I commit this?
>>>
>>> Jacopo
>>>
>>
>

[cjhowe]

I would think wait.  It's a local solution for you
knowing the limitations, but if anyone else used it
without realizing the limitation (and they're rather
obscure), they wouldn't get the results they would be
expecting.

--- Jacopo Cappellato <[hidden email]> wrote:

> Chris, David,
>
> thanks for your interesting comments.
> Just to be sure to understand your comments: is it
> ok if I commit this
> stuff (even if it could not be used under some
> circumstances i.e. a lot
> of parameters, or values containing non-ASCII
> characters) or should I
> wait for a better solution?
>
> Thanks,
> Jacopo
>
> David E Jones wrote:
> >
> > That's a good point Chris. There is also the
> problem of non-ASCII
> > characters in URLs, though we could at least get
> around this problem by
> > having it encode the characters using the \u
> stuff.
> >
> > We could put something like this in as a nice
> tool, and it would be up
> > to the programmer using it to determine if it is
> appropriate for
> > whatever they are writing...
> >
> > -David
> >
> >
> > On Oct 3, 2006, at 8:35 PM, Chris Howe wrote:
> >
> >> that's a good idea.  however because you're using
> GET
> >> instead of POST, you're going to end up with a
> 2048
> >> character limit for the url.  Why not have an
> entity
> >> that can hold larger with a single "queryId" and
> >> simply append that?
> >>
> >> --- Jacopo Cappellato <[hidden email]> wrote:
> >>
> >>> What do you think of the following patch?
> >>>
> >>> Index:
> >>>
> >>
>

framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
> >>>
> >>
>
===================================================================
> >>> ---
> >>>
> >>
>
framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java
> >>>
> >>> (revision 452088)
> >>> +++
> >>>
> >>
>
framework/widget/src/org/ofbiz/widget/screen/ScreenRenderer.java

> >>>
> >>> (working copy)
> >>> @@ -257,6 +257,8 @@
> >>>     TaglibFactory JspTaglibs = new
> >>> TaglibFactory(servletContext);
> >>>     context.put("JspTaglibs", JspTaglibs);
> >>>     context.put("requestParameters",
> >>> UtilHttp.getParameterMap(request));
> >>> +  context.put("requestParametersUrl",
> >>>
> >>
>

UtilHttp.urlEncodeArgs(UtilHttp.getParameterMap(request)));

> >>>
> >>>
> >>>
> >>> It basically adds an url friendly representation
> of
> >>> the parameters
> >>> posted to a screen so that they can be appended
> to a
> >>> link in the page in
> >>> this way:
> >>>
> >>> <link
> target="ExampleReport?${requestParametersUrl}"
> >>> text="Print this
> >>> page" style="buttontext"/>
> >>>
> >>> I need something like this for example when,
> after
> >>> submitting a find
> >>> form I get a list of records and I want to
> display a
> >>> link to get a PDF
> >>> version of the same list: in the link I have to
> >>> append the search
> >>> parameters.
> >>>
> >>> Can I commit this?
> >>>
> >>> Jacopo
> >>>
> >>
> >
>
>

[Jacopo Cappellato]

This makes sense... however the limitations are not so big and I think
that what I've proposed can be used in many other places without big
troubles: the non-ASCII issue is already present in the system (for
example in the product keywords screen) and the max 2048 chars is high
enough to make it usable in most of the screens.

Jacopo

Chris Howe wrote:
> I would think wait.  It's a local solution for you
> knowing the limitations, but if anyone else used it
> without realizing the limitation (and they're rather
> obscure), they wouldn't get the results they would be
> expecting.
>

[cjhowe]

I'm not a malicious hacker type person, but allowing a
parameter map into the url, i believe, also has the
potential to be a security hazzard with buffer
overflow.


--- Jacopo Cappellato <[hidden email]> wrote:

> This makes sense... however the limitations are not
> so big and I think
> that what I've proposed can be used in many other
> places without big
> troubles: the non-ASCII issue is already present in
> the system (for
> example in the product keywords screen) and the max
> 2048 chars is high
> enough to make it usable in most of the screens.
>
> Jacopo
>
> Chris Howe wrote:
> > I would think wait.  It's a local solution for you
> > knowing the limitations, but if anyone else used
> it
> > without realizing the limitation (and they're
> rather
> > obscure), they wouldn't get the results they would
> be
> > expecting.
> >
>
>

[Jacques Le Roux]

Jacopo, Chris, David,

I think this last point is worth to be considered... (relates to https://issues.apache.org/jira/browse/OFBIZ-260)

Jacques

From: "Chris Howe" <[hidden email]>

> I'm not a malicious hacker type person, but allowing a
> parameter map into the url, i believe, also has the
> potential to be a security hazzard with buffer
> overflow.
>
>
> --- Jacopo Cappellato <[hidden email]> wrote:
>
> > This makes sense... however the limitations are not
> > so big and I think
> > that what I've proposed can be used in many other
> > places without big
> > troubles: the non-ASCII issue is already present in
> > the system (for
> > example in the product keywords screen) and the max
> > 2048 chars is high
> > enough to make it usable in most of the screens.
> >
> > Jacopo
> >
> > Chris Howe wrote:
> > > I would think wait.  It's a local solution for you
> > > knowing the limitations, but if anyone else used
> > it
> > > without realizing the limitation (and they're
> > rather
> > > obscure), they wouldn't get the results they would
> > be
> > > expecting.
> > >
> >
> >

[Jacopo Cappellato]

Jacques, Chris, David, all,

it seems that this small mod was causing a few concerns so I ended up
with a totally different solution: in rev. 452778 I've implemented a new
generic screen that can be used to render a link backed up by an hidden
form.
An example of its usage is in rev. 452780
I think with this to have addressed all your remarks.

Thanks for your great feedback,

Jacopo


Jacques Le Roux wrote:

> Jacopo, Chris, David,
>
> I think this last point is worth to be considered... (relates to https://issues.apache.org/jira/browse/OFBIZ-260)
>
> Jacques
>
> From: "Chris Howe" <[hidden email]>
>> I'm not a malicious hacker type person, but allowing a
>> parameter map into the url, i believe, also has the
>> potential to be a security hazzard with buffer
>> overflow.
>>
>>
>> --- Jacopo Cappellato <[hidden email]> wrote:
>>
>>> This makes sense... however the limitations are not
>>> so big and I think
>>> that what I've proposed can be used in many other
>>> places without big
>>> troubles: the non-ASCII issue is already present in
>>> the system (for
>>> example in the product keywords screen) and the max
>>> 2048 chars is high
>>> enough to make it usable in most of the screens.
>>>
>>> Jacopo
>>>
>>> Chris Howe wrote:
>>>> I would think wait.  It's a local solution for you
>>>> knowing the limitations, but if anyone else used
>>> it
>>>> without realizing the limitation (and they're
>>> rather
>>>> obscure), they wouldn't get the results they would
>>> be
>>>> expecting.
>>>>
>>>