portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma" <...@douma.nu>
Subject Re: [J2] Proposal: Handling encoding requirements for the PortalURL
Date Thu, 26 Aug 2004 15:02:42 GMT
Scott T. Weaver said:
> Looks very good Ate! When are you looking to commit your changes? I ask
> this because we are starting to do a lot of portlet development using a
> pre-existing webapp framework and I can already see where your
> refactorings to the PortalURL will probably save us a lot of headaches
> in the future.

I hope to complete the rest of the work before the end of this weekend.

The time I have formally available for J2 has been drastically cut down
since last week though to 1 day/week (at the most). The other days I'm now
working on another project (completely non-portal related). So most of the
work I have to do in my own time, during the evening/night/weekend :-(

So bear with me if it takes a few days longer than that.

>
> Regards,
>
> Ate Douma wrote:
>
>> Currently, the url encoding done by J2 isn't exactly fail prove.
>> For the Struts Portlet Framework (now Portals Struts Bridge) I created
>> a workaround to be able to use embedded url parameters but even that
>> turned out not to work under all situations.
>>
>> Furthermore, there are portlet specification requirements which
>> currently are not met.
>>
>> I have been trying to create a fail prove solution and have already
>> done part of what I propose below.
>> But, to get it completely right turned out to be more complex than I
>> first thought it would.
>> Therefore I first want to present my ideas how to solve this.
>>
>> I'm not sure I covered all requirements and maybe its not fail prove
>> either, so please shoot as much holes in it as possible because the J2
>> project I'm involved in has run in many problems because of this and I
>> need to fix them asap.
>>
>> First I like to specify the (current) definition of a Jetspeed
>> PortalURL as far as I have been able to determine from the code.
>>
>> A Jetspeed PortalURL is build up out of 5 parts:
>>
>>
>> [<baseURL>/<basePath>][/GlobalNavigation][/ControlParameters][?RequestParameters][#LocalNavigation]
>>
>>
>> The [baseURL/basePath] defines the access point to the portal like:
>> [<http://localhost>/<jetspeed/portal>]
>>
>> The [/GlobalNavigation] defines site navigation to folders and pages
>> like:
>> [/], or [/default-page] or [/default-page.psml] for the default page
>> or [/Administrative/pam]
>> or [/rootfolder/subfolder/page]
>> etc.
>>
>> The [/ControlParameters] define statefull portlet specific parameters
>> like for window mode, portlet mode and portlet request parameters.
>> These parameters are encoded in two different ways.
>> Non-portlet request parameters:
>> <prefix><type>_<portletWindowId>/<value>
>> Portlet request parameters
>> <prefix><type>_<portletWindowId>_<parameterName>/<parameterCount>_<parameterValue1>[[_<parameterValue<x>]...]
>>
>>
>> The control parameters prefix and type keys are all externally
>> definable (in spring assembly jetspeed-spring.xml)
>>
>> The [?RequestParameters] define the "normal" url parameters like those
>> of an ActionURL and are encoded as usual:
>> name=value definitions with first parameter prefixed with an '?',
>> additional parameters prefixed with '&'.
>>
>> Finally, the [#LocalNavigation] is only used by a browser to refer to
>> a embedded anchor location.
>>
>>
>>
>> From the above definitions it becomes clear that the values of certain
>> elements might cause havoc on the url parsing as is done
>> by both the servlet environment as well as by jetspeed.
>> Of course, defining the control parameter prefix as '/' clearly will
>> break things, but also using a '/', '_', '?' or '&' within a request
>> parameter
>> name or value will do so.
>>
>> In the portlet 1.0 specification these kind of problems have been
>> recognized and therefore PLT.7.1 SPEC 30:
>> The portlet-container must "x-www-form-urlencoded" encode parameter
>> names and
>> values added to a PortletURL object.
>>
>> Currently, Jetspeed 2 doesn't do this!
>> A light encoding algorithm is implemented which replaces '_', '.',
>> '/', '\r', '\n', '<', '>' and ' ' with hexadecimal representations
>> (0x1, 0x2 etc).
>> But, this is only done for RequestURL parameters and also not as
>> complete as required by the spec. For instance, '?' and '&' characters
>> are currently not encoded.
>>
>> Besides the parameter names and values, other elements also can break
>> the url (parsing).
>> If a folder or page name in the [/GlobalNavigation] part start with
>> the ControlParameter prefix key character Jetspeed won't be able to
>> determine them correctly.
>>
>>
>>
>> To solve these problems I propose the following solution:
>>
>> 1) The control parameter prefix key may not be one of: '/', '?', ' ',
>> or '#'
>>
>> 2) To be able to clearly separate the [/GlobalNavigation] part from
>> the [/ControlParameters] part, all [/GlobalNavigation] (path) elements
>> which start with the control parameter prefix are encoded by putting
>> an additional prefix character in front of it. This character of
>> course then also may not be used
>> as control parameter prefix. A [/GlobalNavigation] path element
>> already starting with this character must also be prefixed with it,
>> escaping it.
>> Which character should be used is a matter of taste. I personally opt
>> for '!'.
>>
>> 3) All the [/ControlParameters] portlet request parameter values must
>> have the '_' character encoded, preferably with only a single
>> character instead of using a multi-character hexadecimal style. This,
>> because values might itself contain such a encoding pattern which then
>> needs to be escaped.
>> I would prefer using a '!' again (no conflict with [/GlobalNavigation]
>> encoding because these encoded values are never at the start of a url
>> path element).
>> If we want to have a clearer distinction another character like '$'
>> would also be good.
>>
>> 4) As per the portlet specification, all the [/ControlParameters]
>> parameter name and values as well as those in the [?RequestParameters]
>> part need to be
>> "x-www-form-urlencoded" encoded which can be done with
>> java.net.URLEncoder.
>>
>> 5) The Url parameter separators '?' and '&' are also allowed to be
>> specified using html escape definitions like &#38 and &amp; for '&'
>> and &#63; for '?'.
>> If those are encoded using the URLEncoder they won't be recognized
>> anymore so they must be properly decoded (into '?' and '&') *before*
>> encoding using the URLEncoder.
>>
>> 6) Within Jetspeed, HttpServletRequest.getPathInfo() may not be used
>> anymore because it will first decode the the path string which can
>> again break the
>> url parsing. Luckily, this can be easily circumvented by using the
>> following statement:
>> String pathInfo =
>> request.getRequestURI().substring(request.getContextPath().length()+
>> request.getServletPath().length());
>>
>>
>> As said above, part of this solution I already have in place (4, 5 and
>> 6).
>> Once we have a solid solution I will also do the required additional
>> changes.
>>
>> Regards,
>>
>> Ate
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>>
>>
>
>
> --
> *******************************************
> *           Scott T. Weaver               *
> *         <weaver@apache.org>             *
> *     <http://www.einnovation.com>        *
> * --------------------------------------  *
> *   Apache Jetspeed Enterprise Portal     *
> *     Apache Pluto Portlet Container      *
> *                                         *
> * OpenEditPro, Website Content Management *
> *     <http://www.openeditpro.com>        *
> *******************************************
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message