Question

Under certain circumstances my desktop app using SharePoint web services ends up with DefaultNetworkCredentials having null values, and so the call fails. I need to then obtain the users credentials, but I haven't found a straightfoward way to do so.

I'm considering implementing the solution outlined in http://www.pinvoke.net/default.aspx/credui/CredUIPromptForCredentialsW.html

... however, this still is going to require that I handle the password, which I'd really rather not do. I've looked, but haven't been able to find a more direct method that prompts the user and returns a NetworkCredential directly, without my having to store the password?

Thanks,

EDIT: It looks like I'm not going to find exactly what I'm looking for... I'll have to prompt the user myself when this happens.

However, if I'm interpreting some of these answers correctly, it may be an error condition for the DefaultNetworkCredentials to be null like this in the first place. Is that the case? Is there a way to force the DefaultNetworkCredentials to populate, or is it really a simple cache that's just remembering the last domain/userid/password used for the target URI (that day? that application/session?).

Was it helpful?

Solution

I don't think you can avoid handling them for the first time. But, you an hook into the Credential Manager so that they will be cached from that point forward. Here's an article on how to do that. It's heavy in p/invoke, but could give your users a more consistent experience.

OTHER TIPS

Work on the underlying issue, the null credentials rather than nagging the user for information they have already entered.

Unless you want them to be able to log into SharePoint differently from thier current account (a useful feature perhaps).

.NET has code for dealing with credentials, so why second guess that by going out to external dll's and adding another dependancy to your app?

I do not know enough about code security risks you have in your environment, but I would have thought that storing the credentials object in client memory only would be "safe enough" for most situations.

I don't know of something that handles the password for you, but SecureString may be of use.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top