Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Not A Defect
-
None
Description
From what I can tell (using Jenkins 1.518), the 'monitor external jobs' feature does not support usernames containing the @ (at sign) character.
This is a big problem for us, since we use LDAP auth, and all our usernames contain the @ sign.
When I use this sequence:
export JENKINS_HOME=https://foo@bar.com:secret@somebox.bar.com
java jar /somepath/jenkins-core*.jar "somejob" pwd
I get this exception:
java.net.MalformedURLException: For input string: "secret@somebox.bar.com"
at java.net.URL.<init>(URL.java:601)
at java.net.URL.<init>(URL.java:464)
at java.net.URL.<init>(URL.java:413)
at hudson.Main.remotePost(Main.java:93)
at hudson.Main.run(Main.java:74)
at hudson.Main.main(Main.java:56)
If there was a way to support multiple auth providers, then this would not be a big deal, since we could store our 'automation users' (the users we would use for monitoring external jobs) in Jenkins and use LDAP for the rest of the users. However, this does not appear to be an option.
Attachments
Activity
https://foo@bar.com:secret@somebox.bar.com/ is not a well-formed URL. I think you meant to use https://foo%40bar.com:secret@somebox.bar.com/ instead.
Steve Roth
added a comment - I see a comment in https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs from zhewei shou on 4/24/2012 indicating the same issue:
>>>
Apr 24, 2012
zhewei shou says:
when i export JENKINS_HOME(which is not localhost path), i need pass username & password. but what can i do if the password exists character like '@'?
>>>
Steve Roth
added a comment - I see a comment in https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs from zhewei shou on 4/24/2012 indicating the same issue:
>>>
Apr 24, 2012
zhewei shou says:
when i export JENKINS_HOME(which is not localhost path), i need pass username & password. but what can i do if the password exists character like '@'?
>>> 
Thanks Jesse. We ended up going a different direction (changing our auth approach, so @xxxx is no longer needed), and this is no longer an issue for us.