DefaultNetworkCredentials a des valeurs nulles. Besoin d'indiquer à l'utilisateur ... Comment?

Question

Dans certaines circonstances, mon application de bureau à l'aide des services Web SharePoint se retrouve avec DefaultNetworkCredentials ayant des valeurs nulles, et donc l'appel échoue. Je dois alors obtenir les informations d'identification des utilisateurs, mais je ne l'ai pas trouvé un moyen straightfoward de le faire.

J'envisage la mise en œuvre de la solution décrite dans http: // www. pinvoke.net/default.aspx/credui/CredUIPromptForCredentialsW.html

... cependant, cela reste va exiger que je gère le mot de passe, que je préfèrerais ne pas faire. Je l'ai regardé, mais n'ont pas été en mesure de trouver une méthode plus directe qui invite l'utilisateur et retourne un NetworkCredential directement, sans que je doive stocker le mot de passe?

Merci,

EDIT: On dirait que je ne vais pas trouver exactement ce que je cherche ... Je vais devoir me inviter l'utilisateur lorsque cela se produit.

Cependant, si j'interprète certaines de ces réponses correctement, il peut être une condition d'erreur pour les DefaultNetworkCredentials à NULL comme celui-ci en premier lieu. Est-ce le cas? Y at-il un moyen de forcer les DefaultNetworkCredentials à peupleront, ou est-il vraiment d'un simple cache qui vient se rappeler le dernier domaine / ID utilisateur / mot de passe utilisé pour l'URI cible (qui de jour? Cette application / séance?).

Answer 1

Je ne pense pas que vous pouvez éviter de les manipuler pour la première fois. Mais, vous un crochet dans le gestionnaire d'informations d'identification afin qu'ils seront mises en cache de ce point en avant. Voici un article sur la façon de le faire . Il est lourd en p / invoquer, mais pourrait donner à vos utilisateurs une expérience plus cohérente.

Answer 2

Les travaux sur la question sous-jacente, les informations d'identification null plutôt que lancinante l'utilisateur des informations qu'ils sont déjà entrés.

Sauf si vous voulez qu'ils soient en mesure de se connecter à SharePoint différemment Thier compte courant (une caractéristique utile peut-être).

.NET a le code pour traiter les informations d'identification, alors pourquoi deviner que en allant à la dll externe de et en ajoutant une autre application à votre dépendance?

Je ne assez sur les risques que vous avez la sécurité de code sais pas dans votre environnement, mais je l'aurais pensé que le stockage des informations d'identification d'objet dans la mémoire client ne serait « assez sûr » pour la plupart des situations.

Answer 3

Je ne sais pas de quelque chose qui gère le mot de passe pour vous, mais securestring peut être utile.