Redirect to Jenkins to pass configuration parameters

Hey all,

we’re currently working on improving our integration between Jira Cloud and Jenkins. The Jenkins plugin we maintain sends build and deployment events to Jira. For this to work, the Jenkins admin needs to configure a URL where to send these events to and a secret used to sign the requests. This URL and secret they get from a screen in Jira.

Now, all of this is working nicely IF the user copies & pastes the URL and secret from Jira correctly, but we’d like to explore if we can improve this user experience by removing the need to copy & paste things between Jira and Jenkins.

So, the question is: how can we get the URL and secret from Jira to Jenkins? We can’t just make a server-to-server call because Jenkins might be behind a firewall. So, we’re thinking of exposing a web page in Jenkins that receives the URL and secret via a redirect in the user’s browser.

I’ve had a look through the docs, and while it looks promising, I didn’t come to a conclusion if this is possible. Before I start digging deep, I thought I’d ask here for opinions :).

Is it possible to build a plugin that exposes a web page in Jenkins that reads query parameters, shows them to the user, and when the user clicks on a button, stores them in our config objects, then redirects back to Jira? Any pointers to examples would be greatly appreciated.



You can make an action (probably a root action since it’s not attached to anything else). Then you need a jelly file to go with that action.

Not the simplest example but the first one that comes to mind…as it’s my plugin… graphql-server-plugin/ at 6fffb7ecb178ae4804ce32bee91185f64c4abaa6 · jenkinsci/graphql-server-plugin · GitHub

That being said. I don’t think I’d be comfortable with th ability for a rogue person to redirect you to a random page and that changes your configuration. Oauth flow at least has multiple hops and confirmations.

Awesome! Thanks for the input and the code example! I’ll dig into that.

Yeah, we’ve thought about the security implications a bit ourselves. The least we should do is to show the user what data came in and have them confirm it before we do anything with it. But we’ll think a bit more about it for sure.

Thanks again!