Comme énoncé dans le billet précédent, l’authentification devient problématique lors des builds. En effet TFS ne pourra pas sans un petit coup de main s’authentifier auprès du serveur Nuget.

Mais Nuget a prévu cette éventualité!

Configuration pour TFS (1/2)

Direction le dossier .nuget (à la racine de la solution par défaut) :

Via Powershell (ou le Package manager) :

• Ajouter le serveur privé en référence:

.\Nuget.exe sources add -Name "MyNugetServer" –Source "http://MonServeurNuget/nuget/" -Conf .\NuGet.Config

Le résultat est visible dans le fichier Nuget.config.

<?xml version="1.0" encoding="utf-8"?> 

    <configuration> 

        <solution> 

            <add key="disableSourceControlIntegration" value="true" /> 

        </solution> 

    <packageSources> 

        <add key="https://www.nuget.org/api/v2/" value="https://www.nuget.org/api/v2/" /> 

        <add key="MyNugetServer" value="http://MonServeurNuget/nuget" /> 

    </packageSources> 

    <disabledPackageSources /> 

</configuration> 

• Il faut désormais préciser les identifiants et les solutions fournies par Nuget sont plus ou moins sécurisées selon le contexte…

Situation 1 : Visual Studio et le serveur de build sont sur la même machine (et utilisé par le même compte) (développement seul)

Via Powershell

.\Nuget.exe sources update -Name "MyNugetServer" -Username "Username" -Password "Password" -Conf .\NuGet.Config 

Resultat :

<?xml version="1.0" encoding="utf-8"?> 

    <configuration> 

        <solution> 

            <add key="disableSourceControlIntegration" value="true" /> 

        </solution> 

    <packageSources> 

        <add key="https://www.nuget.org/api/v2/" value="https://www.nuget.org/api/v2/" /> 

        <add key="MyNugetServer" value="http://MonServeurNuget/nuget" /> 

    </packageSources> 

    <disabledPackageSources /> 

    <packageSourceCredentials> 

        <MyNugetServer> 

            <add key="Username" value="Username" /> 

            <add key="Password" value="MOT DE PASSE CHIFFRE" /> 

        </MyNugetServer> 

    </packageSourceCredentials> 

</configuration> 

Désormais grâce aux identifiants, la build pourra via nuget.exe récuperer les packages Nuget. Le mot de passe est chiffré + la build fonctionne + le serveur est sécurisé :) (le cas du ssl sera vu plus tard)

Situation 2 : Visual Studio et le serveur de build sont sur des machines différentes (ou des comptes différents) (développement en équipe)

Si la méthode précédente est utilisée dans cette situation, une erreur sera levée à la build.

Error : Key not valid for use in specified state

Ce message indique que le mot de passe n’a pas pu être déchiffré.

Explication : Le mot de passe chiffré par Nuget n’est pas portable, en effet Nuget utilise certaines données de la machine (dont le compte courant) pour le chiffrement. De ce fait seul l’utilisateur ayant réalisé le chiffrement pourra déchiffrer le mot de passe.

Une des solutions consiste à se passer tout simplement du chiffrement :

Via Powershell

.\Nuget.exe sources update -Name "MyNugetServer" -User "Username" -Password "Password" -Conf .\NuGet.Config -StorePasswordInClearText 

Résultat :

<?xml version="1.0" encoding="utf-8"?> 

    <configuration> 

        <solution> 

            <add key="disableSourceControlIntegration" value="true" /> 

        </solution> 

    <packageSources> 

        <add key="https://www.nuget.org/api/v2/" value="https://www.nuget.org/api/v2/" /> 

        <add key="MyNugetServer" value="http://MonServeurNuget/nuget" /> 

    </packageSources> 

    <disabledPackageSources /> 

    <packageSourceCredentials> 

        <MyNugetServer> 

            <add key="Username" value="Username" /> 

            <add key="ClearTextPassword" value="MOT DE PASSE EN CLAIR" /> 

        </MyNugetServer> 

    </packageSourceCredentials> 

</configuration> 

Le paramètre StorePasswordInClearText permet de ne plus chiffrer le mot de passe : La build fonctionne + l’authentification côté client aussi mais la sécurité est à revoir...

Une troisième solution, plus sûr, consiste à chiffrer le mot de passe du côté serveur de build pour que TFS puisse le déchiffrer.

En suivant la même démarche que précédemment, cette solution provoquera un bug du côté des clients Visual Studio (ne pouvant pas déchiffrer le mot de passe) dont l’authentification repose en priorité sur le fichier Nuget.Config du dossier .nuget.

Le dernier billet expliquera comment contourner facilement ce problème et offrir une solution facile et rapide à mettre en place tout en offrant un bon niveau de sécurité :)