You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ti...@sastau.it> on 2006/10/03 20:05:01 UTC
What about adding to the context a string representation of the
parameters sent to the page?
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
Re: What about adding to the context a string representation of
the parameters sent to the page?
Posted by Jacopo Cappellato <ti...@sastau.it>.
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" <cj...@yahoo.com>
>> 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 <ti...@sastau.it> 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.
>>>>
>>>
Re: What about adding to the context a string representation of the
parameters sent to the page?
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <cj...@yahoo.com>
> 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 <ti...@sastau.it> 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.
> > >
> >
> >
Re: What about adding to the context a string representation of the parameters sent to the page?
Posted by Chris Howe <cj...@yahoo.com>.
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 <ti...@sastau.it> 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.
> >
>
>
Re: What about adding to the context a string representation of
the parameters sent to the page?
Posted by Jacopo Cappellato <ti...@sastau.it>.
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.
>
Re: What about adding to the context a string representation of the parameters sent to the page?
Posted by Chris Howe <cj...@yahoo.com>.
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 <ti...@sastau.it> 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 <ti...@sastau.it> 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
> >>>
> >>
> >
>
>
Re: What about adding to the context a string representation of
the parameters sent to the page?
Posted by Jacopo Cappellato <ti...@sastau.it>.
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 <ti...@sastau.it> 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
>>>
>>
>
Re: What about adding to the context a string representation of the parameters sent to the page?
Posted by David E Jones <jo...@undersunconsulting.com>.
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 <ti...@sastau.it> 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
>>
>
Re: What about adding to the context a string representation of the parameters sent to the page?
Posted by Chris Howe <cj...@yahoo.com>.
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 <ti...@sastau.it> 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
>