Jetspeed 2
  1. Jetspeed 2
  2. JS2-275

Option to make Action URLs relative or absolute

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.1-dev, 2.1
    • Component/s: None
    • Labels:
      None

      Description

      The portlet:actionURL always generates URLs containing protocol, host and port.
      This new feature would make the generation of either relative or absolute action and render URLs optional.
      A system wide setting would be set to either relative or absolute

      1. j2-secure.patch
        2 kB
        Santiago Gala

        Issue Links

          Activity

          Hide
          Ate Douma added a comment -

          Feature request now fully implemented

          Show
          Ate Douma added a comment - Feature request now fully implemented
          Hide
          Ate Douma added a comment -

          To be able to use relative urls only, the currently used <base> tag poses a problem.
          While most browsers support a relative url value (e.g. /jetspeed/) for the base tag href attribute, most notably IE does NOT (and the w3c specification says it should be an "absolute" url, so Microsoft seems to be right on this once).

          After looking into our usage of the base tag, I don't see any benefit of it and its rather easy to use qualified urls for all our (decoration) resources and not depend on the base tag at all.
          I guess the base tag usage is legacy from the time when we used the content server and our decorations were still hidden beneath /WEB-INF.

          So I'm going to solve this by making all our generated (decoration) resource references properly context relative urls and remove the <base> tag from our demo decorator header.vm templates.

          Note: I won't modify/remove the jetspeed-macros.vm BaseHref macro or the HeaderResource.HEADER_SECTION_BASE_TAG based generation of a base tag like used by the desktop (method HeaderResourceImpl.jetspeedGenerateBasetag()), so custom decorations or desktop themes depending on them will continue to work as is.
          But, to be able to access the portal behind a Proxy front end and get a proper look&feel, you will need to remove the generation of these <base> tags from your custom decoration templates and/or through HeaderResource (assembly/headtag.xml, setting header.basetag) yourself.

          Show
          Ate Douma added a comment - To be able to use relative urls only, the currently used <base> tag poses a problem. While most browsers support a relative url value (e.g. /jetspeed/) for the base tag href attribute, most notably IE does NOT (and the w3c specification says it should be an "absolute" url, so Microsoft seems to be right on this once). After looking into our usage of the base tag, I don't see any benefit of it and its rather easy to use qualified urls for all our (decoration) resources and not depend on the base tag at all. I guess the base tag usage is legacy from the time when we used the content server and our decorations were still hidden beneath /WEB-INF. So I'm going to solve this by making all our generated (decoration) resource references properly context relative urls and remove the <base> tag from our demo decorator header.vm templates. Note: I won't modify/remove the jetspeed-macros.vm BaseHref macro or the HeaderResource.HEADER_SECTION_BASE_TAG based generation of a base tag like used by the desktop (method HeaderResourceImpl.jetspeedGenerateBasetag()), so custom decorations or desktop themes depending on them will continue to work as is. But, to be able to access the portal behind a Proxy front end and get a proper look&feel, you will need to remove the generation of these <base> tags from your custom decoration templates and/or through HeaderResource (assembly/headtag.xml, setting header.basetag) yourself.
          Hide
          Ate Douma added a comment -

          While the patch provided (and applied long time ago) was alright, it really addresses the (albeit related) JS2-204 issue, not this feature request.

          This issue really asks for an option to use only relative urls which is very useful when using a Proxy front end like Apache.
          Just by itself, this would have as side-effect that requesting secure/non-secure (Portlet) urls won't have any effect anymore.
          That is a problem which JS2-204 could (and still can) provide a solution for.

          For many of my clients though, being able to dynamically switch between non-secure and secure urls really isn't that important.
          Usually the whole site is put behind an already secured Apache front end.
          But to be able to do so effectively, especially if the portal has to serve multiple virtual domains, the feature requested by this issue really becomes important.

          I'm therefore reopening this issue and will provide a solution to set a system wide property (in jetspeed.properties) to only use relative urls: portalurl.relative.only
          By default, this setting will be false, but by setting this to true, no scheme, server name and port will be used to prefix portal urls.

          Show
          Ate Douma added a comment - While the patch provided (and applied long time ago) was alright, it really addresses the (albeit related) JS2-204 issue, not this feature request. This issue really asks for an option to use only relative urls which is very useful when using a Proxy front end like Apache. Just by itself, this would have as side-effect that requesting secure/non-secure (Portlet) urls won't have any effect anymore. That is a problem which JS2-204 could (and still can) provide a solution for. For many of my clients though, being able to dynamically switch between non-secure and secure urls really isn't that important. Usually the whole site is put behind an already secured Apache front end. But to be able to do so effectively, especially if the portal has to serve multiple virtual domains, the feature requested by this issue really becomes important. I'm therefore reopening this issue and will provide a solution to set a system wide property (in jetspeed.properties) to only use relative urls: portalurl.relative.only By default, this setting will be false, but by setting this to true, no scheme, server name and port will be used to prefix portal urls.
          Hide
          David Sean Taylor added a comment -

          I reviewed the code. this patch was already applied

          Show
          David Sean Taylor added a comment - I reviewed the code. this patch was already applied
          Hide
          Ate Douma added a comment -

          I looked at the patch and while it doesn't solve the problem at hand, I give it a +1.

          Show
          Ate Douma added a comment - I looked at the patch and while it doesn't solve the problem at hand, I give it a +1.
          Hide
          Santiago Gala added a comment -

          Ate, this is the partial solution I found. It works only for standard port transitions (80->443 and 443->80).

          Beyond this, I guess we'd need some way to access tomcat parameters "redirect", or configure our own.

          At least with this patch J2 makes requests for http if it was doing https and the other way around.
          There is no clear solution that I can see for the general case, as tomcat can be running proxied on 8080
          and use 8443 for SSL, or, like here, have 8082 for proxyed http and 8083 for proxied https.

          Hope this helps, and commit if you don't find it too intrusive.

          Show
          Santiago Gala added a comment - Ate, this is the partial solution I found. It works only for standard port transitions (80->443 and 443->80). Beyond this, I guess we'd need some way to access tomcat parameters "redirect", or configure our own. At least with this patch J2 makes requests for http if it was doing https and the other way around. There is no clear solution that I can see for the general case, as tomcat can be running proxied on 8080 and use 8443 for SSL, or, like here, have 8082 for proxyed http and 8083 for proxied https. Hope this helps, and commit if you don't find it too intrusive.
          Hide
          Ate Douma added a comment -

          This issue is related to JS2-204 which I have looked at a few months ago.
          I already had a fix/solution ready for that based on Pluto's solution: PLUTO-82.
          But, I encountered a difficulty/unclear effect with respect to secure connections.
          I started a discussion on the Pluto dev list which continued in private with Jeremy Boynes (who provided the Pluto solution).
          I intended to open a discussion about it on the Jetspeed list too but got side-tracked and then completely forgot about it.
          I will post the relevant information from Pluto discussion on JS2-204 and maybe we can take it then from there (or here).

          Show
          Ate Douma added a comment - This issue is related to JS2-204 which I have looked at a few months ago. I already had a fix/solution ready for that based on Pluto's solution: PLUTO-82 . But, I encountered a difficulty/unclear effect with respect to secure connections. I started a discussion on the Pluto dev list which continued in private with Jeremy Boynes (who provided the Pluto solution). I intended to open a discussion about it on the Jetspeed list too but got side-tracked and then completely forgot about it. I will post the relevant information from Pluto discussion on JS2-204 and maybe we can take it then from there (or here).

            People

            • Assignee:
              Ate Douma
              Reporter:
              David Sean Taylor
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development