We are currently loadtesting a Sharepoint environment hosted in IIS8.5 (On Windows 2012R2), using Loadrunner 11.52. We are using the WinINET based replay mechanism as there were SSL issues when trying to use the LR sockets implementation.
The authentication for the site is set to allow Windows Authentication. The users are all unique Active Directory users.
We have an issue where after starting 50 users, the users start failing due to them being unable to authenticate.
We have captured both successful (first 50 users) authentication and unsuccessful (users after the first 50) auth using Fiddler.
On initially loading the web page, the server returns a 401 with authentication headers as expected:
Request:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Response:
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
request-id: ad71f69c-0b10-d049-46c6-1f0b1f7bd574
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 2
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
WinINET then handles this appropriately, returning a Kerberos auth token, which the server accepts:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate YIISMQYGKwYBBQUCoIISJTCCEiGgMDAuB...<long-auth-token-string>...=
Response:
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=utf-8
Expires: Wed, 11 Mar 2015 07:13:44 GMT
Last-Modified: Thu, 26 Mar 2015 07:13:44 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
X-AspNet-Version: 4.0.30319
SPRequestGuid: ad71f69c-db17-d049-46c6-15c51828a26e
request-id: ad71f69c-db17-d049-46c6-15c51828a26e
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 40
SPIisLatency: 0
WWW-Authenticate: Negotiate oYGzMIGwoAMKAQChCw...<long auth token>...=
Persistent-Auth: true
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:13:44 GMT
Content-Length: 80492
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html dir="ltr" lang="en-US">
<head><meta name="GENERATOR" content="Microsoft SharePoint" /><
...
Some googling has suggested that the "YIIS" at the beginning of the auth token indicates that it has chosen Kerberos in response to the Negotiate auth option. This works fine for the first 50 users we start (each with unique AD user credentials).
However, for the 51st user, and each subsequent user, WinINET seems to start attempting to use NTLM authentication instead, which the server rejects.
Request (same as previously successful user):
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Response (same as previously successful user):
HTTP/1.1 401 Unauthorized
Content-Type: text/plain; charset=utf-8
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-6b4f-d049-46c6-1e90257415f1
request-id: 6a71f69c-6b4f-d049-46c6-1e90257415f1
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 16
Proxy-Support: Session-Based-Authentication
401 UNAUTHORIZED
Client then sends the request for auth:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAABAAA...<short NTLM auth token>...==
Some googling suggests that the T1R at the start of the auth token means it has chosen to use NTLM this time, instead of Kerberos which was used for all the users up till this one.
The server responds with another 401 to this:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
WWW-Authenticate: Negotiate TlRMTVNTUAACAAAACAAIADgAAAAVgonicMgf76hzy7QAAAAAAAAAAL4AvgBAAA...<long NTLM auth token>=
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
request-id: 6a71f69c-cb6b-d049-46c6-14cbc16d1ea9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 1
SPIisLatency: 0
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
Wininet then sends another auth request as follows:
GET https://myserver/Pages/default.aspx HTTP/1.1
Cookie: WSS_FullScreenMode=false
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Host: myserver
Connection: Keep-Alive
Cache-Control: no-cache
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAKIAAACEAYQBu...<much longer NTLM token>...=
Which results in another 401:
HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5
SPRequestGuid: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
request-id: 6a71f69c-cb6b-d049-46c6-18ce53703ae9
X-FRAME-OPTIONS: SAMEORIGIN
SPRequestDuration: 236
SPIisLatency: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 15.0.0.4667
X-Content-Type-Options: nosniff
X-MS-InvokeApp: 1; RequireReadOnly
Date: Thu, 26 Mar 2015 07:09:10 GMT
Content-Length: 0
Proxy-Support: Session-Based-Authentication
At this point WinINET seems to give up, and passes the 401 on to LoadRunner which then fails the user.
The first 50 users keep working as normal. We can also load another user manually through IE while those 50 are still running. We can also wait some time and eventually we can start more users.
So, there seems to be two issues here:
Why is WinINET changing to use NTLM auth instead of Kerberos after 50 users have been started?
Why is the server rejecting the NTLM auth.
Any ideas on what might be causing this, and/or how I can investigate further, would be very appreciated. My suspicion is that it may be some sort of Active Directory limit that blocks Kerberos from working for a period after 50 users have been authenticated, however I do not know how to prove/disprove that.
Thanks.
Related
Follow link https://learn.microsoft.com/en-us/azure/media-services/previous/media-services-rest-connect-with-aad
Get: https://mediatest1.restv2.SoutheastAsia.media.azure.net/api/Assets
Header:
Content-Type: application/json;odata=verbose
Accept: application/json;odata=verbose
DataServiceVersion: 3.0
MaxDataServiceVersion: 3.0
x-ms-version: 2.19
Host:media.windows.net
Authoriztion: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyIsImtpZCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyJ9.eyJhdWQiOiJodHRwczovL21hbmFnZW1lbnQuY29yZS53aW5kb3dzLm5ldCIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0L2Y2NDI4YTBhLWE1NTItNDg1Yi04Zjg1LWJhNDU3NjA5ZjEyMS8iLCJpYXQiOjE2MTQwODg1NDYsIm5iZiI6MTYxNDA4ODU0NiwiZXhwIjoxNjE0MDkyNDQ2LCJhaW8iOiJFMllBZ3VXNm43WThFSk9YVG4rdStaYlAvd01BIiwiYXBwaWQiOiI2ZTNjNjg3MC1lMjQwLTQ1ZWYtYWVkNS1jYzk3Mjk0MzE0NTEiLCJhcHBpZGFjciI6IjEiLCJpZHAiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9mNjQyOGEwYS1hNTUyLTQ4NWItOGY4NS1iYTQ1NzYwOWYxMjEvIiwib2lkIjoiYzI3MzBhYTAtMDY1My00NzIzLWE0MmItOWJkZWIyOTYzZDAyIiwicmgiOiIwLkFBQUFDb3BDOWxLbFcwaVBoYnBGZGdueElYQm9QRzVBNHU5RnJ0WE1seWxERkZGd0FBQS4iLCJzdWIiOiJjMjczMGFhMC0wNjUzLTQ3MjMtYTQyYi05YmRlYjI5NjNkMDIiLCJ0aWQiOiJmNjQyOGEwYS1hNTUyLTQ4NWItOGY4NS1iYTQ1NzYwOWYxMjEiLCJ1dGkiOiIxM2hOZkNXbjVrcTRSZWRJRGZZQUFBIiwidmVyIjoiMS4wIiwieG1zX3RjZHQiOjE2MTM0Njk0OTh9.WmtlWAuY_UxQDjsx7p7N7hQBP061Mx_CMlMP51bA7yXF4ac7Nr46gs1nrj-lTTKEoEuJXb-k-GiMtcfvDc5ooeEHO-IAC3LIFItlQBtgQ1jcAM3QtwXEY8CLJ7yG6XXCk4GtIDLCrcXfh5hg2qdI06gZFdabeEA2aQDrqFbJFj-u4UIkvnPMklM5xs3szHceYQFtiVbblzS8fTBQfkHdYEDWLQunpwH-_GT5h4O_YVtoElmKWjzHgBDO9rA4XgejWFLNV5KzKSjd31IW2EzFb9DWpdaJP1P8ou9pJ_fQvLMAfzk73F4eR785VIPvOP3gfwgw2OSaboFUO_o1gFpADA
Response:
401
Server: Microsoft-IIS/10.0
request-id: 3e93ef9f-cb7e-4921-8e99-b911469d0020
x-ms-request-id: 3e93ef9f-cb7e-4921-8e99-b911469d0020
access-control-expose-headers: request-id, x-ms-request-id
WWW-Authenticate: Bearer
WWW-Authenticate: Bearer
X-Powered-By: ASP.NET
Strict-Transport-Security: max-age=31536000; includeSubDomains
Date: Tue, 23 Feb 2021 14:20:47 GMT
it is working fine when i using azure sdk
Looking for help as i am struggling for last 6 hours
Thank you in advance
We have a use case in our corporation in which ROPC is deemed secure in which we upload a file to a sharepoint folder. The user has been granted the contributor role. When we log onto sharepoint as the user, she can upload a file.
However, when we try to do the same through our application, we are getting 403 forbidden. Looking at the token we get through ROPC, I see the following:
Files.ReadWrite User.Read profile openid email
Why are we then getting 403 Forbidden when we try to upload the file?
A few more pieces of info:
Consent has been granted by the Administrator for the Delegated permission of Files.ReadWrite.
Application Manifest has allowPublicClient set to true.
In testing this use case, we were able to retrieve a user profile without problem, but for some reason the Files.ReadWrite says not authorized although the user can upload a file no problem from within Sharepoint.
Screenshot of API Permissions:
Decoded token part 1:
Decoded token part 2:
Failing Request:
POST /v1.0/sites/92a99e5f-bb3e-4588-9461-d640b59d52e2/drives/b!X56pkj67iEWUYdZAtZ1S4hDhiQyamFVEj8y19ROdYOKYReOmD1sXSoDAvyFjD733/root:/Miriams%20Folder/FMW%20Management%20EM12c.pptx:/microsoft.graph.createUploadSession HTTP/1.1
SdkVersion: graph-java/v2.4.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6InJNckJTQlBjNnlWZmVGVVZpbXhkYXEwdUpPMDNPQTFIWnZQQ01mV21uLUEiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAvIiwiaWF0IjoxNjA3MzU2NDk1LCJuYmYiOjE2MDczNTY0OTUsImV4cCI6MTYwNzM2MDM5NSwiYWNjdCI6MCwiYWNyIjoiMSIsImFjcnMiOlsidXJuOnVzZXI6cmVnaXN0ZXJzZWN1cml0eWluZm8iLCJ1cm46bWljcm9zb2Z0OnJlcTEiLCJ1cm46bWljcm9zb2Z0OnJlcTIiLCJ1cm46bWljcm9zb2Z0OnJlcTMiLCJjMSIsImMyIiwiYzMiLCJjNCIsImM1IiwiYzYiLCJjNyIsImM4IiwiYzkiLCJjMTAiLCJjMTEiLCJjMTIiLCJjMTMiLCJjMTQiLCJjMTUiLCJjMTYiLCJjMTciLCJjMTgiLCJjMTkiLCJjMjAiLCJjMjEiLCJjMjIiLCJjMjMiLCJjMjQiLCJjMjUiXSwiYWlvIjoiQVNRQTIvOFJBQUFBdUUvM3BaZjlXbE8ySWlaVkJlbzBURDFXK2VWR3o1RHN1YWNYRHF5VTU3WT0iLCJhbXIiOlsicHdkIl0sImFwcF9kaXNwbGF5bmFtZSI6ImFjY2VzcyBsZWVzIGZvbGRlciIsImFwcGlkIjoiOTkzNjQzNzktNDVhMC00ZGZhLTlkOTQtZDlhNDEwNTJjZDFjIiwiYXBwaWRhY3IiOiIwIiwiZmFtaWx5X25hbWUiOiJHcmFoYW0iLCJnaXZlbl9uYW1lIjoiTWlyaWFtIiwiaWR0eXAiOiJ1c2VyIiwiaXBhZGRyIjoiMjE2Ljk5LjE4MC4xNjMiLCJuYW1lIjoiTWlyaWFtIEdyYWhhbSIsIm9pZCI6IjZjODJiY2E3LTE5NjAtNGM1MS1iNjFjLWE3NDg3MTYyM2Y5ZiIsInBsYXRmIjoiMTQiLCJwdWlkIjoiMTAwMzIwMDBGMTZFRkNCRSIsInJoIjoiMC5BQUFBS1QyNWZOMHRRRW1sd0pYRk5uWXRrSGxETnBtZ1JmcE5uWlRacEJCU3pSeDFBTzAuIiwic2NwIjoiRmlsZXMuUmVhZFdyaXRlIG9wZW5pZCBwcm9maWxlIFJvbGVNYW5hZ2VtZW50LlJlYWQuQWxsIFJvbGVNYW5hZ2VtZW50LlJlYWQuRGlyZWN0b3J5IFVzZXIuUmVhZCBlbWFpbCIsInN1YiI6Im1MdTA4WFczc0RmNlF1c0lxZmVtRjViUUdySDlGYkRzQ0JLZ2w1RnljcXMiLCJ0ZW5hbnRfcmVnaW9uX3Njb3BlIjoiTkEiLCJ0aWQiOiI3Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAiLCJ1bmlxdWVfbmFtZSI6Ik1pcmlhbUdAdDg3N3NyZi5vbm1pY3Jvc29mdC5jb20iLCJ1cG4iOiJNaXJpYW1HQHQ4NzdzcmYub25taWNyb3NvZnQuY29tIiwidXRpIjoiR3U5V2FfalRORXFHSUJrdS0xaTlBQSIsInZlciI6IjEuMCIsIndpZHMiOlsiYjc5ZmJmNGQtM2VmOS00Njg5LTgxNDMtNzZiMTk0ZTg1NTA5Il0sInhtc19zdCI6eyJzdWIiOiJDQTFnQkttVU9nLVplc3otMEFmOWF1VVFHOHY0a283MlNoVGp1eEFlSjFNIn0sInhtc190Y2R0IjoxNjAzNzI3NjA4fQ.x5xY4qWUKQdYNOwlj0GWP0f8ICT10ojCQ1CKUoffDYm2W5FGKUMOZPx11dhZv6W2ye1Tm0v3Yd6lMm9nWOkXf5LhILLmLptX1SCA7K0fQ-ttgZRhFrtPf3_sEycaTDMTSIS4WtoDlQ1Z3kjv17F0N56cxWnmZli9YFPJCD54YZZingBzfZI4pd96XvuE9aVaZiB1P92kg7veMIjYczgvDgMijtTSnVgzzF06Uip0eRG5oQhnmz1VwLG2djJFPeu6Xm2zvsIF4-FTxDzEmjq-JQVo2GupAUVxVtUyZyrEsGupu763gpEfOvkgusKPnByZdPXGA1cPksosAA0fe4kbnA
Accept: */*
SdkVersion: graph-java-core/v1.0.5 (featureUsage=0) java/1.8.0_131
client-request-id: edea4a1e-b722-4980-a688-ce1699af69bd
Content-Type: application/json
Content-Length: 11
Host: graph.microsoft.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.10.0-RC1
Failing Response (ROPC):
HTTP/1.1 403 Forbidden
Cache-Control: private
Content-Type: application/json
request-id: f00286fd-5ae6-488e-afd6-475ae7846906
client-request-id: edea4a1e-b722-4980-a688-ce1699af69bd
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"SliceC","Ring":"2","ScaleUnit":"000","RoleInstance":"AGSFE_IN_71"}}
Strict-Transport-Security: max-age=31536000
Date: Mon, 07 Dec 2020 15:59:59 GMT
Content-Length: 279
Successful Request (client_credentials)
POST /v1.0/sites/92a99e5f-bb3e-4588-9461-d640b59d52e2/drives/b!X56pkj67iEWUYdZAtZ1S4hDhiQyamFVEj8y19ROdYOKYReOmD1sXSoDAvyFjD733/root:/Miriams%20Folder/FMW%20Management%20EM12c.pptx:/microsoft.graph.createUploadSession HTTP/1.1
SdkVersion: graph-java/v2.4.1
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6Imp0M3ZlaW5pVkZPZTc1R0I5RG40Uk0ydEJlWTRkUEZOYTFiaDQwR1RFMmMiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCIsImtpZCI6ImtnMkxZczJUMENUaklmajRydDZKSXluZW4zOCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83Y2I5M2QyOS0yZGRkLTQ5NDAtYTVjMC05NWM1MzY3NjJkOTAvIiwiaWF0IjoxNjA3MzcyMDQxLCJuYmYiOjE2MDczNzIwNDEsImV4cCI6MTYwNzM3NTk0MSwiYWlvIjoiRTJSZ1lIZ2hFR1ZwODBpdXhmcFl2V3ZYa1Y4YUFBPT0iLCJhcHBfZGlzcGxheW5hbWUiOiJhY2Nlc3MgbGVlcyBmb2xkZXIiLCJhcHBpZCI6Ijk5MzY0Mzc5LTQ1YTAtNGRmYS05ZDk0LWQ5YTQxMDUyY2QxYyIsImFwcGlkYWNyIjoiMSIsImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzdjYjkzZDI5LTJkZGQtNDk0MC1hNWMwLTk1YzUzNjc2MmQ5MC8iLCJpZHR5cCI6ImFwcCIsIm9pZCI6IjllNWIzYzM1LWNjYzAtNDk5Zi04NjExLTA2Yjc2MmM0NzNlYiIsInJoIjoiMC5BQUFBS1QyNWZOMHRRRW1sd0pYRk5uWXRrSGxETnBtZ1JmcE5uWlRacEJCU3pSeDFBQUEuIiwicm9sZXMiOlsiU2l0ZXMuUmVhZFdyaXRlLkFsbCIsIkZpbGVzLlJlYWRXcml0ZS5BbGwiLCJVc2VyLlJlYWQuQWxsIl0sInN1YiI6IjllNWIzYzM1LWNjYzAtNDk5Zi04NjExLTA2Yjc2MmM0NzNlYiIsInRlbmFudF9yZWdpb25fc2NvcGUiOiJOQSIsInRpZCI6IjdjYjkzZDI5LTJkZGQtNDk0MC1hNWMwLTk1YzUzNjc2MmQ5MCIsInV0aSI6Ilg3aTdIa1N3VGttal9jMW5zbWNYQUEiLCJ2ZXIiOiIxLjAiLCJ4bXNfdGNkdCI6MTYwMzcyNzYwOH0.AIj32kpkwVZiU6OM038yb4m7KQkQZ65PYSYGgS0M_ONhymtxhq7c1XAY-oTTw6jSyApb7d8lI37er-Qi9f47KXvhfEZlrpG0lX4ZOBcuqbPQagOTETT6Tn6FI5LKtIRm7SP2rICNUNzLuXip5D3_3i4Oil0AENQfu4eLjXr6YA5yIfjp4JUx_Ylh8eV9B0QM-na2BZLdrI3RfM0SY2ifFArxcWKQoaNUDinHYE952Wb5-SdgiX16Bi5-dN6LJiIhu4kScn3pHVbbpunBbk7aDTaPaqFeO7uuLycPIIkbu7vStTVX0mmRUXeg2wL6bU9tWo5YT5X93hi7oMYpoyQkNg
Accept: */*
SdkVersion: graph-java-core/v1.0.5 (featureUsage=0) java/1.8.0_131
client-request-id: 147bd003-d380-49ec-aa5a-6f18adef0021
Content-Type: application/json
Content-Length: 11
Host: graph.microsoft.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.10.0-RC1
Successful Response (client_credentials)
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8
Location: https://graph.microsoft.com
Vary: Accept-Encoding
request-id: bc409fcf-f957-4477-8e02-05d06f4724f1
client-request-id: 147bd003-d380-49ec-aa5a-6f18adef0021
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"North Central US","Slice":"SliceC","Ring":"3","ScaleUnit":"002","RoleInstance":"AGSFE_IN_12"}}
OData-Version: 4.0
Strict-Transport-Security: max-age=31536000
Date: Mon, 07 Dec 2020 20:19:04 GMT
Content-Length: 1473
FOR SUCCESSFUL RUN, this is followed by
CONNECT t877srf.sharepoint.com:443 HTTP/1.1
Host: t877srf.sharepoint.com:443
Connection: Keep-Alive
User-Agent: okhttp/4.10.0-RC1
Plus all the chunking
Issue encountered was due to the simple fact that the folder we are uploading to is not the root folder. For root Folder, Files.ReadWrite is sufficient; for other folders the permission Files.ReadWrite.All is required.
I'm trying to integrate Gmail API in my app in order to send emails to users.
i've created a project on Google Developers Console, enabled Gamil API in it, downloaded the credentials as JSON and followed the instruction provided at https://developers.google.com/gmail/api/quickstart/nodejs
I've also added https://developers.google.com/oauthplayground as a redirect URI for the project.
When I run the code, I get redirected to a consent screen. I choose the account which has the project, then get redirected to "oauthplayground"
However, when I try to exchange authorization code for tokens, I receive 401 unauthorized
the full response is:
HTTP/1.1 401 Unauthorized
Content-length: 75
X-xss-protection: 0
X-content-type-options: nosniff
Transfer-encoding: chunked
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Vary: Origin, X-Origin, Referer
Server: scaffolding on HTTPServer2
-content-encoding: gzip
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 21 Oct 2020 07:53:18 GMT
X-frame-options: SAMEORIGIN
Alt-svc: h3-Q050=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
Content-type: application/json; charset=utf-8
{
"error_description": "Unauthorized",
"error": "unauthorized_client"
}
Any help is appreciated
Thanks
What is the best way to get IIS to set the headers for woff files so that they can be served from the client browser cache.
I'm working on an MVC .NET site that is hosted in IIS7.5, served through cloudflare with static caching turned on. The site uses a custom woff web font. When requests are made for pages that use these fonts IIS is serving them with the headers shown below. Subsequent requests all look the same. To me it looks like these are not getting cached by the client browser. I'd expect the server to be responding with 304 (Not Modified) and then the browser should serve the woff from its cache.
Request Headers
GET /blah/Content/fonts/AzoSans-Thin-webfont.woff HTTP/1.1
Host: blah.co.uk
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36
Accept: */*
DNT: 1
Referer: http://blah.co.uk/bundles/Content/stylesheets/main?v=f9NXr53WMUdV9DfYJMkEU_5QZZi0g8eB1lB5lqxgdXc1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Cookie: __cfduid=d96b367152ae58725c15e5946cf1d67f41415385741070; ASP.NET_SessionId=3tcc3e1nd0z005tlknrbph5h; redesign#lang=en
Response Headers
HTTP/1.1 200 OK
Date: Fri, 07 Nov 2014 19:27:57 GMT
Content-Type: application/font-woff
Content-Length: 27728
Connection: keep-alive
Last-Modified: Thu, 06 Mar 2014 10:40:46 GMT
ETag: "0cbfc872839cf1:0"
X-Powered-By: ASP.NET
CF-Cache-Status: HIT
Vary: Accept-Encoding
Expires: Fri, 07 Nov 2014 23:27:57 GMT
Cache-Control: public, max-age=14400
Accept-Ranges: bytes
Server: cloudflare-nginx
CF-RAY: 185bee60092d0a90-LHR
The problem here seems to be that cloudflare is changing the headers. If I bypass cloudflare I get
Cache-Control:max-age=0
and the server responds with a 304 and the browser uses content from its cache.
I have created a site in Sharepoint services and hosted in IIS 6.0, the site is revealing few sensitive information like server name in the response. Please help me to secure or hide this information. The request and response is as given below (sensitive information is marked in bold lines).
Request –
GET /Finance/_layouts/userdisp.aspx HTTP/1.1
Host: (Server IP)
Accept: */*
Accept-Language: en
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
Connection: close
Response –
HTTP/1.1 200 OK
Date: Wed, 29 Jun 2011 00:08:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
MicrosoftSharePointTeamServices: 12.0.0.6421
X-AspNet-Version: 2.0.50727
Set-Cookie: WSS_KeepSessionAuthenticated=443; path=/
Set-Cookie: MSOWebPartPage_AnonymousAccessCookie=443; expires=Wed, 29-Jun-2011 00:38:33 GMT; path=/
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Length: 32318
You can hide the Server Name reported in the headers by using URLScan:
http://www.iis.net/download/urlscan