Is it possible to do a webservice call from within an Excel sheet that has been downloaded from a sharepoint server, using the same credentials as the ones that are used for accessing the Sharepoint server?
We're currently developing an Excel solution, which does webservice request from within the Excel sheet. This works fine, but the user has to log in at least twice : one for downloading/opening the Excel sheet from Sharepoint, and one to be able to execute the webservice using the right credentials.
The Sharepoint server and the client machine are not in the same Active Directory domain. So "System.Security.Principal.WindowsIdentity.GetCurrent()" is not an option, since this will return a user that doesn't exist on the server.
You can use VSTO (Visual Studio Tools For Office) to create an Excel plugin. The plugin gets loaded every time you open the Excel and can contain buttons etc.
To use the system account of Sharepoint you must use RunWithElevatedPrivileges. This has some security implications!
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx
Normally the webservices take the logged-in user credentials into account.
if not you can always manually create them by using NetworkCredential class.
System.Net.CredentialCache myCredentials = new System.Net.CredentialCache();
NetworkCredential netCred = new NetworkCredential("UserName", "Password");
myCredentials.Add(new Uri(myService.Url), "Basic", netCred);
myService.Credentials = myCredentials;
// Acces your webservice methods here
Related
We had our client create a new sandbox for us to test imports without workflows (imports work on the original sandbox.) I'm authenticated into D365 using an Active Directory app with a certificate sent from the C# code and my thought process was to just replace all instances of the old base url of {sandbox-name}.api.crm.dynamics or {sandbox-name}.crm.dynamics with {new-sandbox-name}.api.crm.dynamics and {new-sandbox-name}.crm.dynamics. I'm getting a 401 error now when trying to import data.
I can't find in the Active Directory app where the certificate that we created is tied only to that original sandbox url, so is there something obvious I'm missing?
In your new Sandbox D365 CRM, go and create the Application user in system user table with the right security role/privilege. Then it should work.
Read more
I'm trying to call a Web API 2 method that requires auth from a console app running on my desktop where I have authorization, but I'm getting 401 Unathorized. I know I have authorization because when I make the same call from a web browser it works fine. So a browser can get my default login id/pw to send to the API but .NET's WebClient can't? That seems insane. There has to be a way to do this without entering my id/pw into the console app.
The below is what I'm using in a console app and it's not working.
This is using Windows Auth as it's intranet stuff.
This throws an exception "The remote server returned an error: (401) Unauthorized."
using(var c = new WebClient())
{
c.UseDefaultCredentials = true;
string value = c.DownloadString("http://localhost:62659/api/Store/GetData");
}
I also tried the below and when I mouse over DefaultNetworkCredentials the username/pw are blank strings. Why wouldn't .NET be able to figure this out?
using(var c = new WebClient())
{
var creds = new CredentialCache();
var uri = new Uri("http://localhost:62659/api/Store/GetData");
creds.Add(uri, "ntlm", System.Net.CredentialCache.DefaultNetworkCredentials);
c.Credentials = creds;
string value = c.DownloadString(uri);
}
It is likely that you do not have your credential information stored within Windows Credential Manager. You can access that via Control Panel > Credential Manager. From there you can add whatever credential you need. CredentialCache.DefaultCredentials and CredentialCache.DefaultNetworkCredentials contains the login credentials of the currently logged-in or impersonated user. If what you are connecting to requires different credentials then these will not work. You will need to add those credentials to the Credential Manager in Windows.
The reason you are connecting fine within Chrome is that Chrome will store credentials within itself that you have designated to save.
Login credentials being used as functional ids can be set to never expire, or it will need to be added to a list of monthly/yearly maintenance items to update the password for those accounts.
You would also want to handle bad login information within your application. If this is an automated task, have it email or otherwise notify someone that the credentials need to be updated.
If a user runs this, you could simply prompt the current user to provide a new password, which you can use to update the stored credentials right then.
Another option would be to set the user running the application as a user on the receiving end using those same credentials. That way the entire process is tied to the user(s) that will be running the application.
Using DefaultCredentials should work to use Windows Auth from console application. As long as you have the appropriate authorization header that your web api is looking for. Same with my comment I recommend testing the api call using Postman so that you can troubleshoot and check what you are missing.
Regarding the credentials as blank, this is maybe because you are using DefaultNetworkCredentials.
Try this:
using(var c = new WebClient())
{
var uri = new Uri("http://localhost:62659/api/Store/GetData");
c.Credentials = System.Net.CredentialCache.DefaultCredentials;
string value = c.DownloadString(uri);
}
If you want to use NetworkCredential you should be inputting network credentials like so:
c.Credentials = new NetworkCredential(username, password, domain);
I created this type of console application and used it as a service and I can tell you that this should work. You should just need to troubleshoot and bits by bits get the real problem.
I am tring to use the .Net WebClient object to PUT a file to a sharepoint library using basic authentication, it works in sharepoint 2010 in classic mode but does not work in Sharepoint 2013 in Claims mode.
public static void UploadFile(string remoteFileURL, byte[] file)
{
WebClient webclient = new WebClient();
webclient.Credentials = new NetworkCredential("username", "password", "domain");
webclient.UploadData(remoteFileURL, "PUT", file);
webclient.Dispose();
}
The 401 Unauthorized error is an HTTP status code that means the page you were trying to access can not be loaded until you first log on with a valid user ID and password.
If you received the 401 Unauthorized error, it means that the credentials you entered were invalid for some reason.
In your case you are making a put request. On a browser 401 prompts you to input valid credentials until you click on cancel.
Considering that it worked on SharePoint 2010, these could be the possible errors : -
The credentials you are using are not valid in the SharePoint 2013 server
SharePoint 2013 server is configured to disable pull requests
The user you are trying use does not have access privileges to perform a pull request
From my search on claims mode, I found out that there is a setup which involves adding/migrating users in claims mode which uses a different form of authentication. I think this might be your issue and you should try to check the validity of credentials and access privileges of user you are working with.
Could be a number of dependencies:
Does the account have access?
Is WebDav a contingency?
Maybe this link might help, but it requires CSOM C#
So I have a windows forms application that loads an infopath form(.xml) from a sharepoint library, and does some processing to it. I created an exe out of it and I just supply a sharepoint library url to it through cmd and it pulls up the form.
I also have a web service which runs on an IIS server that calls the exe and displays infomartion for specific users. Now the problem is when I call the exe from then web service, it kept on asking for a login prompt. So i figured the web service must be running as a System account, and i supplied credentals through a number of ways
WebRequest request = WebRequest.Create(sharepoint_url);
request.Credentials = CredentialCache.DefaultNetworkCredentials;
or
request.Credentials = new NetworkCredential("","");
I also tried System.Net.CredentialCache mycache = new System.Net.CredentialCache();
mycache.Add(formUrlName, "Basic", new System.Net.NetworkCredential("", "")); and
request.Credentials = mycache;
But all the time i got an exception being thrown....Infopath cannot open this frm...the signature on this form is not from a trusted publisher.
Then I tried loading my project along with the web service and creating a new form ( Form form2 = new Form()), but doing the authentication procedure first. Now I get a http 401 unauthorized error.
(I use FormControl.Open(url) to open the form fromm the sharepoint library)
What am i doing wrong?
UPDATE:
I checked with the admin of the sharepoint library...apparently, the credentials are not being received at all. I dont know if they are not being sent properly or whether sharepoint is just dropping the credentials and not accepting it.
I am having trouble doing something simple like the following
using (SPSite site = new SPSite(topLevelSite))
{
SPWeb rootWeb = site.OpenWeb();
SPWeb newWeb = rootWeb.Webs.Add(siteName, "abc", "abc",1033,template,false,false);
}
But the catch I am trying to add a site to a PKI enabled sharepoint site:
This code works fine when I am dealing with my non pki sharepoint server, but I get the error:
"
The Web Application at https://server/sites/newSite could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system admin may need to add a new request URL mapping to the intended application.
"
My main question is: How do you go about accessing with C# a sharepoint site that is PKI enabled? Do I need to insert my certs somewhere programmatically or what?
Are there steps before I open SPSite, or are there other Objects I need to use that are more PKI friendly?
I would first make sure that the URL you use is the same URL SharePoint itself knows about. This thing is called Alternate Access Mapping and is accessible through the Central Administration. Sometimes people would map the web application to a different URL using DNS and IIS configuration only, without updating SharePoint itself. It might appear to be working correctly when browsing the site, but this kind of error would appear when using the API