-
Notifications
You must be signed in to change notification settings - Fork 33
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
Conversation
// 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
// 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. |
There was a problem hiding this comment.
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.
...esources/org/jenkinsci/plugins/displayurlapi/DefaultProviderGlobalConfiguration/config.jelly
Outdated
Show resolved
Hide resolved
@@ -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; |
There was a problem hiding this comment.
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.
assertEquals(root + "job/my%20folder/job/my%20job/1/" + TestSysPropDisplayURLProvider.EXTRA_CONTENT_IN_URL, | ||
DisplayURLProvider.get().getRunURL(run)); |
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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
.
src/main/java/org/jenkinsci/plugins/displayurlapi/actions/AbstractDisplayAction.java
Show resolved
Hide resolved
…ider and delete redundant test class
There was a problem hiding this comment.
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
.
There was a problem hiding this 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
…facing text, and rename GlobalConfiguration
...n/java/org/jenkinsci/plugins/displayurlapi/DefaultDisplayURLProviderGlobalConfiguration.java
Outdated
Show resolved
Hide resolved
...esources/org/jenkinsci/plugins/displayurlapi/DefaultProviderGlobalConfiguration/config.jelly
Outdated
Show resolved
Hide resolved
There was a problem hiding this 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.
I'll merge this once the CI build passes and then file a PR to set up CD. |
all good you can merge and I can cut a release if you need it. |
@olamy thanks! I have permission to release too, but I'm setting up CD in #203 and jenkins-infra/repository-permissions-updater#3484 |
release 2.3.9 done |
FYI in case of interest in improving documentation: jenkins-infra/jenkins.io#6137 |
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:
DisplayURLProviderImpl.INSTANCE
, which gives us/display/redirect
links, never direct links to a specific provider URLDisplayURLProvider.getDefault
is no longer context-sensitive, it just returns the extension instance forClassicDisplayURLProvider
(fixes possible infinite recursion inblueocean-display-url-provider
)DisplayURLProvider.getPreferredProvider
has been updated to resolve redirects in a consistent way, taking all possible configuration options into accountAbstractDisplayAction.lookupProvider
delegates toDisplayURLProvider.getPreferredProvider
DefaultProviderGlobalConfiguration
class that allows admins to select a default provider in the GUITesting 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