Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-43205][JENKINS-69006] Allow admins to configure a global default URL provider and always make external links go through /display/redirect #202

Merged
merged 7 commits into from Aug 17, 2023

Conversation

dwnusbaum
Copy link
Member

@dwnusbaum dwnusbaum commented Aug 14, 2023

See JENKINS-43205. This PR provides a new global configuration option for admins to select the default URL provider for /display/redirect links.

It also tries to address various issues caused by #42 noted in JENKINS-69006.

The main changes are as follows:

  • When producing redirect links, we always use DisplayURLProviderImpl.INSTANCE, which gives us /display/redirect links, never direct links to a specific provider URL
  • DisplayURLProvider.getDefault is no longer context-sensitive, it just returns the extension instance for ClassicDisplayURLProvider (fixes possible infinite recursion in blueocean-display-url-provider)
  • DisplayURLProvider.getPreferredProvider has been updated to resolve redirects in a consistent way, taking all possible configuration options into account
  • AbstractDisplayAction.lookupProvider delegates to DisplayURLProvider.getPreferredProvider
  • There is a new DefaultProviderGlobalConfiguration class that allows admins to select a default provider in the GUI

Testing done

I added a new test that exercises DefaultProviderGlobalConfiguration. Other tests were adjusted as needed. Honestly though there seems to be a huge amount of redundancy in the tests here; I am tempted to throw them all out and start over.

Submitter checklist

Edit tasklist title
Beta Give feedback Tasklist Submitter checklist, more options

Delete tasklist

Delete tasklist block?
Are you sure? All relationships in this tasklist will be removed.
  1. Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
    Options
  2. Ensure that the pull request title represents the desired changelog entry
    Options
  3. Please describe what you did
    Options
  4. Link to relevant issues in GitHub or Jira
    Options
  5. Link to relevant pull requests, esp. upstream and downstream changes
    Options
  6. Ensure you have provided tests - that demonstrates feature works or fixes the issue
    Options

Comment on lines 31 to 34
// TODO: Would it not make more sense to return DisplayURLProviderImpl.INSTANCE unconditionally, always
// serving /display/redirect URLs that only get resolved when an actual user clicks on them? There is no
// guarantee that the current user (if any) is going to be the user who clicks the generated link so IDK why we
// take the current user's preferences into account here.
Copy link
Member Author

@dwnusbaum dwnusbaum Aug 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method only gets used when generating links, not when following them, so it doesn't make sense to me to consider user preferences here. In practice I don't think it matters because almost no one uses authorize-project and so this more or less always gets called in a context where there is no active user, but it is confusing when looking at the code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out it used to work the way I had in mind prior to #42, and JENKINS-69006 is asking for it to be switched back, so I will look into fixing that issue while I am here.

Comment on lines 196 to 197
// Note that this logic means that `/display/redirect` links will never be produced when using the environment
// variable or system property, meaning that it effetively disables user preferences.
Copy link
Member Author

@dwnusbaum dwnusbaum Aug 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, the system properties are really a way to completely disable the effects of this plugin without having to uninstall it.

@dwnusbaum dwnusbaum changed the title Allow admins to configure a global default URL provider [JENKINS-43205][JENKINS-69006] Allow admins to configure a global default URL provider and always make external links go through /display/redirect Aug 16, 2023
@@ -28,8 +38,7 @@ public abstract class DisplayURLProvider implements ExtensionPoint {
* @return DisplayURLProvider
*/
public static DisplayURLProvider get() {
DisplayURLProvider preferredProvider = getPreferredProvider();
return preferredProvider != null ? preferredProvider : DisplayURLProviderImpl.INSTANCE;
return DisplayURLProviderImpl.INSTANCE;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As before #42. See discussion in JENKINS-69006.

Comment on lines -116 to -117
assertEquals(root + "job/my%20folder/job/my%20job/1/" + TestSysPropDisplayURLProvider.EXTRA_CONTENT_IN_URL,
DisplayURLProvider.get().getRunURL(run));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test shows the exact issue described in JENKINS-69006 - /display/redirect was bypassed entirely and the external URL was static.


String root = DisplayURLProvider.get().getRoot();
assertEquals("http://localhost:" + rule.getLocalPort() + "/jenkins/", root);
assertEquals(root + "job/my%20folder/job/my%20job/1/" + TestUserDisplayURLProvider.EXTRA_CONTENT_IN_URL,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, although in practice I think this case can only be hit if you use something like authorize-project.

@dwnusbaum dwnusbaum marked this pull request as ready for review August 16, 2023 19:33
@dwnusbaum dwnusbaum requested a review from a team as a code owner August 16, 2023 19:33
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test class did not meaningfully increase coverage and required a @VisibleForTest method that was awkward to preserve with the changes to AbstractDisplayAction.

Copy link

@julieheard julieheard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks sensible to me

Copy link
Contributor

@car-roll car-roll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, though I am not familiar enough with this plugin to look beyond just the pure functionality of the code here.

@dwnusbaum
Copy link
Member Author

I'll merge this once the CI build passes and then file a PR to set up CD.

@olamy
Copy link
Member

olamy commented Aug 17, 2023

all good you can merge and I can cut a release if you need it.

@dwnusbaum
Copy link
Member Author

@olamy thanks! I have permission to release too, but I'm setting up CD in #203 and jenkins-infra/repository-permissions-updater#3484

@dwnusbaum dwnusbaum merged commit ab54d9d into jenkinsci:master Aug 17, 2023
15 checks passed
@dwnusbaum dwnusbaum deleted the default-provider branch August 17, 2023 21:09
@olamy
Copy link
Member

olamy commented Aug 18, 2023

release 2.3.9 done

@timja
Copy link
Member

timja commented Aug 19, 2023

FYI in case of interest in improving documentation: jenkins-infra/jenkins.io#6137

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants