Re: [gatein-dev] Resolved NodePath in PortalRequestContext

On 07/30/2013 12:58 PM, Julien Viet wrote: > Hi, > > I don't know about the functional validity of this change (yet), but technically speaking you should never use java.net.URLDecoder for encoding or decoding strings. Not sure what you mean here. I'm not encoding and decoding. I removed the line that used EntityEncoder to encode the path in PortalRequestHandler. This was added to fix XSS exploit, however it caused issues. > > Why do you need to decode the URL created by NodeURL.toString() ? Because it's an encoded value. For example a path of /home/ábá in NodeURL would be /home/%C3%A1b%C3%A1.

> > On Jul 30, 2013, at 6:23 PM, Nick Scavelli <nscavell(a)redhat.com&gt; wrote: > >> TLDR: eXo.env.server.portalBaseURL and eXo.env.server.portalURLTemplate have changed to include only the resolved path. >> >> I've made a change (http://git.io/ogoWhw) which has only been applied to master so it can resonate a bit in hopes there are no issues. I have added a resolvedNodePath field to PortalRequestContext (even though I think nodePath should be changed) to represent the resolved path of the portal. Meaning if I go to URL /portal/classic/home/foo the resolved path is just /home not /home/foo. >> >> The reason for this change was that a fix was applied to decode the nodePath in order to avoid XSS in the URL since we use this value to create the JavaScript variables eXo.env.server.portalBaseURL and eXo.env.server.portalURLTemplate. However this caused an issue for non-ascii node names since the route couldn't be found after decoding. I think the resolvedNodePath is a better solution however it does change the behavior of the JS variables I mentioned. >> >> If anyone sees a potential issue with this solution please discuss here. >> >> - Nick >> _______________________________________________ >> gatein-dev mailing list >> gatein-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/gatein-dev >