Credentials plugin: Domain and credentials not saved in user configuration page

[Moral]

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 

[Stephen Connolly]

It's a bug

--
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-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stephen Connolly]

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

[Alberto Morando]

Hi Stephen,

Thanks for the help.

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.

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.

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.al...@gmail.com>

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

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-use...@googlegroups.com.

[Stephen Connolly]

On 23 August 2013 10:00, Alberto Morando <alb.m...@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.

[Alberto Morando]

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.al...@gmail.com>