Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-53261

Blue ocean should handle non-encoded URLs for jobs in folders

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • blueocean-plugin
    • None

      Two important points: 1) we're using jobs inside of folders, sometimes up to 4 levels deep, 2) we're sending links in email notifications to our users for failed builds, etc. As it turns out Outlook 365 has ATP (Active Threat Protection) which wraps URLs from "unknown" or not specifically whitelisted addresses in another site controlled by MS.

      I've confirmed using http://www.o365atp.com/ that the URL encoding for the full job path (i.e. /blue/organizations/jenkins/folder%2Fjob/detail/...) is correct in the wrapped link.
      Unfortunately, their ATP endpoints returns a 302 with a location that has been URL decoded one too many times, so that I end up with /blue/organizations/jenkins/folder/job/detail/...). This fails to load in blue ocean since it does not handle job paths with actual slashes instead of URL encoded slashes (%2F).

      Obviously the best answer is that MS should fix their stuff, but I don't think that's going to happen anytime soon. I can also workaround this by using nginx rewrites since we are behind nginx. However, those rewrites are messy and difficult to get right for arbitrary depths of folders.

      IMHO, blue ocean should be able to handle paths that are not URL encoded for jobs, since there are markers before and after the job (/jenkins/ and /detail/, etc). Is there a chance that we could improve the URL routing to handle this? I'm happy to take a look myself, but I'm not sure where the actual routing is being done for blue ocean.

          [JENKINS-53261] Blue ocean should handle non-encoded URLs for jobs in folders

          It looks like some browsers like Chrome think they are smart and they replace the %2F with a / making it an URL blue ocean doesn't expect. I kind of understand why Chrome might do this, but it doesn't help us here. Consider using a more safe separator (maybe configurable)

          Robert Scholte added a comment - It looks like some browsers like Chrome think they are smart and they replace the %2F with a / making it an URL blue ocean doesn't expect. I kind of understand why Chrome might do this, but it doesn't help us here. Consider using a more safe separator (maybe configurable)

          same issue here: following "Open Blue Ocean" link in the left menu of https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/ brings me to "Page not found (404)"
          I'm using Firefox 65.0 and Chromium 71.0.3578.98

          Hervé Boutemy added a comment - same issue here: following "Open Blue Ocean" link in the left menu of https://builds.apache.org/view/M-R/view/Maven/job/maven-box/job/maven/ brings me to "Page not found (404)" I'm using Firefox 65.0 and Chromium 71.0.3578.98

          Euclid Sun added a comment - - edited

          A workaround is to create links that are appended with a / forcing the browser to not encode anything in the URL and read it as-is with no replacements. If we could have urls from the plugin show up automatically appended with / this would solve a large amount of issues so long as no one tries to post a link from the dashboard without the /

          However it is still a workaround

          a fix would be reading the folder names and reserving 

          blue/organizations/jenkins

          detail

          \d+/pipeline

          as reserve words so that the labels for folders can be read in correctly regardless if they are replaced

          Euclid Sun added a comment - - edited A workaround is to create links that are appended with a / forcing the browser to not encode anything in the URL and read it as-is with no replacements. If we could have urls from the plugin show up automatically appended with / this would solve a large amount of issues so long as no one tries to post a link from the dashboard without the / However it is still a workaround a fix would be reading the folder names and reserving  blue/organizations/jenkins detail \d+/pipeline as reserve words so that the labels for folders can be read in correctly regardless if they are replaced

          Brian Saville added a comment -

          Was working on my nginx proxy which I haven't touched in years, and noticed that I figured out this redirect scheme (or "borrowed" it from SO). Thought I'd share here in case it helps anyone else:

              if ($request_uri ~* "(.*/organizations/jenkins/)(.+)/(.+)(/detail/.*)") {
                  set $slash %%2F;
                  rewrite ^(.*/organizations/jenkins/)(.+)/(.+)/(.+)(/detail/.*)$ $1$2$slash$3$slash$4$5;
                  rewrite ^(.*/organizations/jenkins/)(.+)/(.+)(/detail/.*)$ $1$2$slash$3$4 redirect;
              }
          

          Brian Saville added a comment - Was working on my nginx proxy which I haven't touched in years, and noticed that I figured out this redirect scheme (or "borrowed" it from SO). Thought I'd share here in case it helps anyone else: if ($request_uri ~* "(.*/organizations/jenkins/)(.+)/(.+)(/detail/.*)") { set $slash %%2F; rewrite ^(.*/organizations/jenkins/)(.+)/(.+)/(.+)(/detail/.*)$ $1$2$slash$3$slash$4$5; rewrite ^(.*/organizations/jenkins/)(.+)/(.+)(/detail/.*)$ $1$2$slash$3$4 redirect; }

            Unassigned Unassigned
            bksaville Brian Saville
            Votes:
            6 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: