On 23 August 2013 10:00, Alberto Morando <[email protected]> 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 <[email protected]>
>
>> https://issues.jenkins-ci.org/browse/JENKINS-19308
>>
>>
>> On 22 August 2013 09:43, Stephen Connolly <
>> [email protected]> wrote:
>>
>>> It's a bug
>>>
>>>
>>> On 22 August 2013 09:08, Moral <[email protected]> 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 [email protected].
>>>> 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
>> [email protected].
>>
>> 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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to