Active Choices Reactive Reference - iFrame options

[Steven Spierenburg]

Hi All,

I'm trying to form an idea where I can have a custom asp/form on the build page where I have a lot more control over what the user can select, what and how things are rendered, basically a little webapp that is included on the "build with parameters" page. The goal is to present users with a UI I can control. 

The route I'm investigating right now it to have the "Active Choices Reactive Reference" defined as parameter and include an iframe via the option "formatted HTML"

I'm struggling with the "src" part of the iframe.

Here is an example that will work, you have basically Jenkins inside Jenkins:
return "<iframe src=\"/\" width=500 height=300 />"

The root is set as source and that is of course Jenkins itself, this works

But any other option I try seems to fail. Either the iframe will not render or it will show an error message.

Here is an example I would like to use, it is a reference on the same Jenkins server but pointing to IIS serving ASP/ASPX pages:

return "<iframe src=\"https://jenkins_server_address:5050/NiceUIForm.aspx\" width=500 height=300 />"

Nothing happens, a blank iframe area is shown.

When I try something very simple, like referencing another website I get the same blank iframe:

return "<iframe src=\"https://www.w3schools.com\" width=500 height=300 />"

So what I'm looking for is some guidance on using the "src" parameter on an iframe when used inside the "Active Choices Reactive Reference Parameter"

Also, a hint on how to communicate information to the form called and back again to the build job would be really nice!

I can see some info being transferred to the form called via URL parameters and communicating back to Jenkins/build in the form of hidden fields but I might have that idea wrong, if anybody could give a hint it would really help.

Thanks!

[Bruno P. Kinoshita]

Hi Steven,

Interesting use case. Maybe your browser is complaining about the iframe due to some security policy in place?

Like https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options ?

Take a look at the browser console to see if it tells you anything.

Cheers

Bruno

---

--
You received this message because you are subscribed to the Google Groups "BioUno Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to biouno-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Steven Spierenburg]

Hi Bruno,

 

Yep, if I can succeed I will have the best of 2 worlds I hope. Jenkins doing what Jenkins does best but end-user UI is not it’s best feature, it was never intended to be so I guess.

However, in these times we see a lot of “empowerment” to members of different teams to a) offload the workload from DevOps and b) to have team member be able to execute systems tasks without the need to DevOps.

But exposing team members to the “bare bones” UI of Jenkins when setting parameters is not going to cut it. We need more control, more visual aids and more access to logic behind the scenes.

Presenting the users with a decent UI form which we can control via PHP, APSX, Python, Etc. will make for a rich and guided experience they are looking for and also are expecting these days.

 

Ok, I checked and I do not think x-frame-options is the problem. I could not find a setting easily. Truth be told, I was not the one who installed this Jenkins environment so it’s a challenge to find out what is set where ☺

 

I did take a look at the console and saw something interesting:

Blocked loading mixed active content “http://jenkins_address/user/steven_spierenburg/”

 

However, this is the Groovy script for the parameter:

return "<iframe src=\"https:// jenkins_address /user/steven_spierenburg\" width=500 height=300 />"

 

Seems that https was turned into http somehow?

 

https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content

 

 

Any suggestions what I could do about this?

 

Met vriendelijke groet / Warm regards,

 

Steven Spierenburg

 

E spier...@gmail.com

M +31 (0) 6 303 38 087

--
You received this message because you are subscribed to a topic in the Google Groups "BioUno Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/biouno-users/fRFrh31j5Ik/unsubscribe.
To unsubscribe from this group and all its topics, send an email to biouno-users...@googlegroups.com.

[Steven Spierenburg]

Hi Bruno,

 

Tried it with address “'https://www.w3schools.com” and got this response:

 

Refused to display 'https://www.w3schools.com/' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

build?delay=0sec:222 GET https://www.w3schools.com/ net::ERR_BLOCKED_BY_RESPONSE

 

I think Jenkins is blocking access?

https://issues.jenkins-ci.org/browse/JENKINS-21881

 

Or is that for the other way around, blocking embedding Jenkins in another site?

[Ioannis Moutsatsos]

Hi Steven;

The situation around Jenkins security blocking useful functionality for end users is not pretty!

I wish we could find the perfect solution, but I'm not sure we are there yet. Many useful features related especially to use of dynamic HTML, javascript and Groovy are not working correctly due to security issues.

But you are on the right path if you want o build sophisticated UIs using just Jenkins. I have done this now and the workhorse for this functionality is Active Choices (now backlisted due to a Scriptler dependency).

I would forgo the iFrame and build the functionality you need right into the build form with Active Choices, dynamic HTML, javascript and anything else you want (I even have an embedded H2 db cache controlled by Active Choices)

Here is an example (hopefully) demonstrating the complexity of UIs you can build utilizing functionality from Active Choices.

[Steven Spierenburg]

Hi Ionannis,

That looks pretty cool! I will try some things and see how far I will get

Another "path" that I might examine is using html forms and linking them to Jenkins jobs via the remote API (i.e. press a button and the right URL with API token and parameters in the URL)

Semi/abstract plan would be to have a SharePOint list where I create records for users to click, these represent the forms. Click on a link in that SP record and you get redirected to a HTML form, we do our thing in there and a URL will be fired towards Jenkins.

SharepointList -> Record -> Info + URL field -> click URL field -> a form made for a particular Jenkins job is presented -> user presses "OK" button -> Jenkins job gets fired -> results I need to think about, some sort of browse somewhere :-)

Advantages are that nobody sees Jenkins, I can prepare the jobs as I want (will never be called by users directly, sort of a "raw" job), company protects SharePoint via SSO already, API token prevents illegal usage (you need to give you API token in the form on a field), etc.

Many possibilities :-)