Hi Stephen, Thanks for the info.
I forgot to mention that the credentials are need to access our SCM tool. WE use SCM Surround and this tool is using LDAP credentials. Whar I want o achieveis: 1) ecah Jenkins user has only one plca where to save SCM Surround credential (i.e. LDAP credentials) 2) In each job that uses SCM Surround commands these credentials shall be used At the moment we inject SCM Surround credentials using Password Parameters nad the envinject plug in. But this is not a good solution since the LDAP credentials (used by SCM Surround) are changed every 6 month and jenkins users must change the Password parameters in all the job. So if we get the solution 1. is good since we can have the credentials saved in one place (e.g. user credentials page) and used in all the Credential job paramter type. If we use the solution 2. we still have issues since: a. 2013/8/23 Stephen Connolly <stephen.alan.conno...@gmail.com> > On 23 August 2013 10:00, Alberto Morando <alb.mora...@gmail.com> wrote: > >> Hi Stephen, >> >> Thanks for the help. >> > > Thanks for reporting the issue. > > >> >> Now I have downloaded the new credentials plug in version (1.7.4) and I >> would like to use the credentials I have saved in the user configuration >> page (I can see that now :-)). >> >> I was thinking to use the credentials in all the job that need them. In >> this way the paasword is saved only in one place adn if we need to change >> it we do it only in the user configuration page. >> > > The issue here is that the credentials belong to the user and the job runs > not as the user but as ACL.SYSTEM, thus the job will not have access to the > user's credentials. > > To give the job access to the users credentials there are two routes I can > see: > > 1. A Credentials job parameter (I will probably look at adding this to the > credentials plugin in the near future... it is an "obvious" requirement > that everyone will need) > > or > > 2. Put the credentials in the system store, i.e. Jenkins | Manage Jenkins > | Manage Credentials... Credentials with Global scope are available to all > jobs.... or if you are using the CloudBees Folders plugin, you can put the > credentials in the folder so that they are available only for jobs in the > folder. > > FYI credentials are divided up on a number of different axes: > > * Authorization: i.e. which authentications can access them > > * Scope: i.e. what objects within Jenkins can access them > > * Domains: i.e. when credentials are appropriate based on the context in > which they will be used. > > * Type: i.e. are these username/password, client certificate, ssh keys, etc > > > >> To be able to do that I would like to use the extensions point provided >> by the credential plug: >> >> The credentials plugin provides two main extension points: >> >> - Credentials - a base class for all Credentials types managed by the >> credentials plugin. Most plugin authors will just want to subclass this >> type to define what they need to store in the credential type... better >> yet, if you can find an existing Credentials subclass that stores your >> credentials. So, for example, if somebody created a ssh-credentials >> plugin >> that just defines a SshCredentials class, then anyone needing ssh >> credentials could just depend on that... [Note that careful use of >> readResolve can allow this to be introduced after the fact] >> - CredentialsProvider - an extension point for something that can >> provide credentials. For example, the CloudBees Folders plugin uses this >> extension point to provide folder scoped credentials, so that the >> credentials are only available to jobs within the folder. >> >> How I can use them? >> >> I have never developed a plug in but I was thinking that maybe I can >> write a groovy script in the job build step and then save the credentials >> in environment variable. >> > > You might want to take a look at the ssh-agent plugin for the type of > thing you are looking to do... cribbing from that would allow you to inject > the username and password as environment variables in the context of your > build... though I do question the sensibility of putting a password in an > environment variable. > > I would tend to think a better option would be to have a command that > returns the password injected as the environment variable, e.g. > SSH_ASKPASS=somecommandyouinjectontheslave > > The SSH_ASKPASS command typically is provided with the prompt string as > the list of arguments and echos the password to stdout. > > A bare bones version would be > > #!/bin/sh > echo "password" > > or, on windows: > > @echo off > echo "password" > > You would just write the file to a temporary location on the build slave, > give it the execute permissions and then pass the absolute path to that > file as the SSH_ASKPASS environment variable. > > >> >> Could you please point me out if this is a good solution or which >> solution I can look at? >> >> Thanks >> >> Alberto >> >> >> 2013/8/22 Stephen Connolly <stephen.alan.conno...@gmail.com> >> >>> https://issues.jenkins-ci.org/browse/JENKINS-19308 >>> >>> >>> On 22 August 2013 09:43, Stephen Connolly < >>> stephen.alan.conno...@gmail.com> wrote: >>> >>>> It's a bug >>>> >>>> >>>> On 22 August 2013 09:08, Moral <alb.mora...@gmail.com> wrote: >>>> >>>>> Hi >>>>> >>>>> My system has: >>>>> >>>>> Tomcat Apache: 7.0.32 >>>>> >>>>> Jenkins 1.528 >>>>> >>>>> Credentials plug in: 1.7.3 >>>>> >>>>> I go to the <jenkins Server>/jenkins/asynchPeople/ >>>>> >>>>> I choose my ID profile >>>>> >>>>> I choose the configure option >>>>> >>>>> I can see that it is now possible to save Credential Domains >>>>> >>>>> I fill in all the info and click Apply and Save >>>>> >>>>> I reenter to the configure page but the Credential Domain I have >>>>> entered before is gone... >>>>> >>>>> >>>>> Why? >>>>> >>>>> Is there someone that knows if I am doing something wrong or is the >>>>> Credential Plug in failing? >>>>> >>>>> thanks >>>>> >>>>> Alberto >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Users" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to jenkinsci-users+unsubscr...@googlegroups.com. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Jenkins Users" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/jenkinsci-users/j3kE07NI3MU/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> jenkinsci-users+unsubscr...@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to jenkinsci-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-users/j3kE07NI3MU/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > jenkinsci-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
