I have a SharePoint provider hosted app deployed on Azure, with ASP.NET MVC. Because we chose to use AngularJS, we have added ASP.NET Web API controllers as well. We have managed to create the SharePoint client context in the API controllers by sharing the token information from the MVC controllers via cookies (the API controllers actions have a SharePointApiContextFilter just as the MVC controllers have the SharePointContextFilter to handle the SharePoint client context creation).
I have added an OData controller for reporting purposes, which will export data to Excel (via Excel's OData Data Feed import). I would like to make this controller to authenticate against SharePoint online. Excel has already implemented this functionality, since I have tried to import data from a SharePoint library via REST.
Using Fiddler, I have noticed the SharePoint online returns a 401 response with a authentication challenge (WWW-Authenticate) header:
WWW-Authenticate: IDCRL Type="BPOSIDCRL",
EndPoint="/sites/Test/_vti_bin/idcrl.svc/",
RootDomain="sharepoint.com", Policy="MBI"
This is the full response:
HTTP/1.1 401 Unauthorized Cache-Control: private, max-age=0
Content-Length: 0 Content-Type: application/xml;charset=utf-8 Expires:
Tue, 07 Jul 2015 07:34:08 GMT Last-Modified: Wed, 22 Jul 2015 07:34:08
GMT Server: Microsoft-IIS/8.5 X-SharePointHealthScore: 0
X-MSDAVEXT_Error: 917656;
Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.
DATASERVICEVERSION: 3.0 X-AspNet-Version: 4.0.30319 SPRequestGuid:
be6d1c9d-806b-2000-20ed-4d42443d8365 request-id:
be6d1c9d-806b-2000-20ed-4d42443d8365 X-FRAME-OPTIONS: SAMEORIGIN
X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 16.0.0.4121
X-Content-Type-Options: nosniff X-MS-InvokeApp: 1; RequireReadOnly
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo
OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI" WWW-Authenticate: IDCRL
Type="BPOSIDCRL", EndPoint="/sites/Test/_vti_bin/idcrl.svc/",
RootDomain="sharepoint.com", Policy="MBI" Date: Wed, 22 Jul 2015
07:34:08 GMT
Can somebody tell me how to construct this type of response in the OData controller (maybe via a custom action filter)?
Related
I'm trying to call the Office 365 SharePoint API at tenant.sharepoint.com with an App Only token, but am getting a 401 response with the message:
The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.
As this is in Office 365, I don't have access to the server to configure it and turn on error messages as suggested in the error message.
I have set up my Azure AD App Registration for app-only access, as described here, including the read and write managed metadata and manage all site collections application permissions.
I request the app-only token like so:
POST https://login.microsoftonline.com/f48cf683-1ba8-469a-82b5-930241ed093d/oauth2/token HTTP/1.1
host: login.microsoftonline.com
content-type: application/x-www-form-urlencoded
content-length: 1071
Request-Context: appId=cid-v1:a8ad1180-5e49-43f7-99e1-3d07c1ffa794
Connection: close
grant_type=client_credentials&client_id=a0e75d70-178a-48c3-94a9-4be5d97ea0c5&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&
client_assertion=*xxx*&resource=https%3A%2F%2Fpeterreayqa.sharepoint.com
(Assertion *xxx* omitted)
I get the response back:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
x-ms-request-id: 03fa7b0e-d725-4730-b20c-26ff0e6e4200
P3P: CP="DSP CUR OTPi IND OTRi ONL FIN"
Set-Cookie: fpc=AfblxFAuBLNAo-WGH3FHRtau4ePVAQAzNMUKpE_WCA; expires=Fri, 21-Dec-2018 11:25:29 GMT; path=/; secure; HttpOnly
Set-Cookie: x-ms-gateway-slice=003; path=/; secure; HttpOnly
Set-Cookie: stsservicecookie=ests; path=/; secure; HttpOnly
Date: Wed, 21 Nov 2018 11:25:29 GMT
Connection: close
Content-Length: 1420
{"token_type":"Bearer","expires_in":"3599","ext_expires_in":"3599","expires_on":"1542803129","not_before":"1542799229","resource":"https://peterreayqa.sharepoint.com","access_token":"*xxx*"}
(Token *xxx* omitted)
Then when I try to call the SharePoint API:
POST https://peterreayqa.sharepoint.com/sites/Sage-NewSharePointTest/sageData/_vti_bin/sites.asmx HTTP/1.1
Authorization: Bearer *xxx*
User-Agent: ISV|Sage|OverDriveUserManagement/1.2
Content-Type: text/xml
SOAPAction: http://schemas.microsoft.com/sharepoint/soap/GetUpdatedFormDigestInformation
X-RequestForceAuthentication: true
Host: peterreayqa.sharepoint.com
Content-Length: 356
Expect: 100-continue
Accept-Encoding: gzip, deflate
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetUpdatedFormDigestInformation xmlns="http://schemas.microsoft.com/sharepoint/soap/" />
</soap:Body>
</soap:Envelope>
(Token *xxx* from previous response is omitted)
I get the following response:
HTTP/1.1 401 Unauthorized
Content-Length: 453
P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
WWW-Authenticate: Bearer realm="f48cf683-1ba8-469a-82b5-930241ed093d",client_id="00000003-0000-0ff1-ce00-000000000000",trusted_issuers="00000001-0000-0000-c000-000000000000#*,D3776938-3DBA-481F-A652-4BEDFCAB7CD8#*,https://sts.windows.net/*/,00000003-0000-0ff1-ce00-000000000000#90140122-8516-11e1-8eff-49304924019b",authorization_uri="https://login.windows.net/common/oauth2/authorize"
x-ms-diagnostics: 3001000;reason="There has been an error authenticating the request.";category="invalid_client"
SPRequestGuid: 3e83a49e-40a8-0000-3740-5cec03406519
request-id: 3e83a49e-40a8-0000-3740-5cec03406519
MS-CV: nqSDPqhAAAA3QFzsA0BlGQ.0
Strict-Transport-Security: max-age=31536000
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 25
SPIisLatency: 1
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 16.0.0.8314
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
X-MSEdge-Ref: Ref A: 8C79E743EAB84728B1865357085F3AA0 Ref B: LON21EDGE1413 Ref C: 2018-11-21T11:28:12Z
Date: Wed, 21 Nov 2018 11:28:11 GMT
{"error_description":"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}
Has anyone encountered this before?
Two suggestions:
First, make sure an Admin has 'Granted' the requested permissions
for the relevant app registration in the Azure portal. In the
article you linked above, they used a Powershell command to do so. If you are using the Azure portal API, it's a separate button.
Also, confirm that the self-signed security certificate was
correctly added to the Azure app registration manifest. You can do
so by downloading the manifest for the relevant Azure app
registration, and opening to view the entries. This article should
help:
https://blogs.msdn.microsoft.com/bobgerman/2017/06/25/calling-sharepoint-csom-from-azure-functions-part-2/
has any one tried accessing sharepoint webservices using soapui.
i am getting a 401 unauthorized error in response to my webservice request.
here is a response for reference :-
HTTP/1.1 401 Unauthor Server: Microsoft-IIS/8.0
SPRequestGuid: 8bf28e9c-d9b2-9011-4ed2-bb557583d071
request-id: 8bf28e9c-d9b2-9011-4ed2-bb557583d071
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 3
SPIisLatency: 2
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4420
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 08 May 2014 17:57:46 GMT
Content-Length: 16
401 UNAUTHORIZEDized
kindly advise.
the authentication methodology is claims based.
regards
Santosh
SoapUI doesn't seem to work directly with NTLM authentication, but you can use a proxy such as Burp Suite to do the authentication for you.
This is explained here:
http://forum.soapui.org/viewtopic.php?t=17431
I was able to overcome this error by including Apache HTTPClientCommon API.
Getting exception while trying to access token from Azure AD by using ADAL from Console client.
Steps:
I have configured Azure AD with my Web API application localhost:44307.
Added the required configuration for Client Id, Client Key.
Followed the work around by changing manifest suggested in this link.
https://www.google.com/search?q=AADSTS50001+%2B+azure+AD+athentication&oq=AADSTS50001+%2B+azure+AD+athentication&aqs=chrome..69i57.10202j0j7&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8#q=AADSTS50001&safe=active
ADAL Version Using: Microsoft.IdentityModel.Clients.ActiveDirectory 2.6.0-alpha
Console App Code:
void GetToken()
{
clientId = "be6b055a-4efc-222a-2187-49657e6f4f1b";
string ClientKey = "c/uIMlsqn9SzJLKKyBle42Ym+tgcaC2tbMlWxJQawE";
string ClientCredential clientCred = new ClientCredential(clientId, ClientKey);
authenticationContext = new AuthenticationContext("https://login.windows.net/MyDevAD.onmicrosoft.com");
authenticationResult = authenticationContext.AcquireToken("https://mylocalwebapiapp.com/", clientCred);
....
}
Fiddler Input:
POST https: //login.windows.net/MyDevAD.onmicrosoft.com/oauth2/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
client-request-id: 53262b17-1234-4ed9-bdb3-748d332eb44b
return-client-request-id: true
x-client-SKU: .NET
x-client-Ver: 2.6.0.0
x-client-CPU: x64
x-client-OS: Microsoft Windows NT 6.3.9600.0
Host: login.windows.net
Content-Length: 185
Expect: 100-continue
Connection: Keep-Alive
grant_type=client_credentials&resource=https%3A%2F%2Flocalhost%3A44307%2F&client_id=be6b055a-4efc-408a-8187-42137e6f4f1b&client_secret=c%2FuIMlsqn9SzJLKKyBle123Ym%2BtgcaC3tbMlWxJQawE%3D
Fiddler Output:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Set-Cookie: x-ms-gateway-slice=ProductionB; path=/
x-ms-request-id: e89741b2-570d-44f6-9e71-6533b083abcd
client-request-id: 35262b17-4771-4ed9-bdb3-748d332eb33b
X-Content-Type-Options: nosniff
X-Powered-By: ARR/3.0
X-Powered-By: ASP.NET
Date: Tue, 01 Apr 2014 19:05:51 GMT
Content-Length: 438
{"error":"invalid_resource","error_description":"AADSTS50001: Resource 'https://mylocalwebapiapp.com/' is not registered for the account.\r\nTrace ID: e89741b2-570d-44f6-9e71-6533b083cdad\r\nCorrelation ID: 35262b17-4771-4ed9-cddb3-748d332eb44b\r\nTimestamp: 2014-04-01 19:05:53Z","error_codes":[50001],"timestamp":"2014-04-01 19:05:53Z","trace_id":"e89741b2-570d-44f6-9e71-6533b083cdad","correlation_id":"35262b17-4771-4ed9-bdb3-748d332eb44b"}
Note: Posted URLS and ID's are faked ones.
We should not have introduced any changes. I would recommend to double check that you assigned to your client app the correct permissions for accessing your web API. Please note that your app is getting a token with its own credentials, hence you need to assign app permissions directly (as opposed to delegated permissions).
HTH
V.
We've successfully configured IIS to front 2 Tomcat instances using isapi_redirect.dll. It's doing everything smartly, and we've been very happy. Now, however, we're using one of the Tomcat instances to serve up web services through AXIS. This requires BASIC Auth, and .NET clients are failing.
+ .NET clients can bypass IIS by surfing to "site:8180" and they're fine
+ Java clients can hit IIS and ISAPI passes them through and they authenticate just fine using basic.
+ .NET clients that hit IIS fail to authenticate using the same unpw.
Fiddler reports this session:
HTTP/1.1 401 Unauthorized
Date: Wed, 07 Jan 2009 14:31:59 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
WWW-Authenticate: Basic realm="Daily Control Module"
Content-Type: text/html;charset=utf-8
Content-Length: 954
Proxy-Support: Session-Based-Authentication
It kicks up what looks like a basic auth dialog, but instead of asking us to auth against Daily Control Module, it asks us to auth against the Windows server. And sure enough, the IIS server is asking for an NTLM auth. If I set the entire server to use Basic Auth, I get this from Fiddler:
HTTP/1.1 401 Unauthorized
Content-Length: 1656
Content-Type: text/html
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="serverName"
X-Powered-By: ASP.NET
Date: Wed, 07 Jan 2009 15:08:32 GMT
Sigh. Basic, but now the Basic Realm is changed to the IIS server. So, if I set the entire server to authenticate against Basic realm, Daily Control Module, then I get this:
HTTP/1.1 401 Unauthorized
Date: Wed, 07 Jan 2009 15:11:45 GMT
Server: Microsoft-IIS/6.0
WWW-Authenticate: Basic realm="Daily Control Module"
X-Powered-By: ASP.NET
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
WWW-Authenticate: Basic realm="Daily Control Module"
Content-Type: text/html;charset=utf-8
Content-Length: 954
Weird with the dual WWW-Auth headers, no? At any rate, authenticating using same unpw that works directly against Tomcat fails, whether I specify the domain or not.
At this time:
+ Anon is Off
+ Integrated Windows Auth is Off
+ Basic auth is On, with the realm configured as Daily Control Module
Thanks for looking.
What is the configuration of the directory security?
Are you sure that only basic authentication is enabled?
Other point is. Maybe in the iis level you should use anonymous authentication. And tomcat is taking care of implementing the basic authentication interchange?
The source of the problem ( from the header you posted ) is that the .net client recognize that the site support ntlm authentication. And try to authenticate with that protocol. The java client is just ignoring the ntlm option so it use whatever other authentication protocol the site supports.
You should make sure that the integrated authentication is not enabled in the site and file level.
We published an application update to the same Azure web app service and started getting errors:
Exception: System.Web.Mvc.HttpAntiForgeryException (0x80004005): The anti-forgery token could not be decrypted. If this application is hosted by a Web Farm or cluster, ensure that all machines are running the same version of ASP.NET Web Pages and that the configuration specifies explicit encryption and validation keys. AutoGenerate cannot be used in a cluster.
This happens to clients using a login page within the app. These are the response headers:
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 5585
Content-Type: text/html; charset=utf-8
Vary: Accept-Encoding
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.2
X-Frame-Options: SAMEORIGIN
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 30 Jan 2019 14:23:33 GMT
The client has to either close the browser and reopen or clear the browser's cookies to fix the problem.
The web app was running 3 app service instances before and after the upgrade. ARR Affinity is on.
Why is this happening and how do I fix it?
Have a look at this answer. Since this issue has just started happening, verify that you don't have a inadvertant calls to #Html.AntiForgeryToken() between veiws.