I'm trying out the Azure Mobile App API and getting an error on making Patch calls.
GET and POST and DELETE works fine.
Here is what my url looks like:
PATCH http://mymobileappapi.azurewebsites.net/tables/Skill/c89027fa-edce-4d36-b42a-ecb0920ebab6
body:
{
"name": "Leadership SDFF"
}
I have these as headers too (as I said other http verbs work.)
ZUMO-API-VERSION 2.0.0
Content-Type Application/Json
And I get 500 error back with this in the body:
{
"error": "An item to update was not provided"
}
The same id works when I do a GET using that id...
And when I make the same call using same body with PUT i get a 404 Not found without any content in the response body.
Any ideas?
It turns out our implementation requires the content-type header value to be lower case, i.e. application/json works, whereas Application/Json doesn't. I've updated this issue to be the placeholder for the fix. As a workaround in the meantime, make the value for the content-type header lower case.
https://github.com/Azure/azure-mobile-apps-node/blob/master/src/express/middleware/parseItem.js#L27
should use req.get instead of req.headers. Keep in mind that values can also include encoding, e.g. application/json; charset=utf-8
Here is link to the issue:
https://github.com/Azure/azure-mobile-apps-node/issues/368
Related
I started using the Azure Maps API on a project using Logic Apps (Azure). All of a sudden the HTTP action stopped working and I am getting a 400 BadRequest Error.
"error": {
"code": "400 BadRequest",
"message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive."
However, when I call the same API using Postman or my browser, it works fine.
API: https://atlas.microsoft.com/search/fuzzy/json?api-version=1.0&subscription-key=xxxxxxxxxxxxxxxxxxxxxxxxxxx&query=2 5 Donlands Ave 4 Toronto Toronto &countrySet=Ca&maxFuzzyLevel=2&limit=1
As I mentioned, this was working and all of a sudden started failing on Logic Apps without making any changes.
I exactly have the same issue.
I use address rest api to retrieve cities from postal code.
Sample :
https://atlas.microsoft.com/search/address/structured/json?subscription-key=mySubcriptionKey&api-version=1.0&postalcode=35000&countrycode=fr&limit=1
Like you, if I use the query client side, I have a 400 bad request with message :
{
"error": {
"code": "400 BadRequest",
"message": "Bad request: one or more parameters were incorrectly specified or are mutually exclusive."
}
}
Please note that the query is OK for google chrome, but return a 400 bad requests with Brave, Edge (chromium) and Firefox.
Note also that the sample web sdk have the same issue and is not updated.
Currently, I don't have any idea about where is the problem.
Edit : After some investigation, i'm pretty sure that it's a Microsoft issue.
So, I found a workaround.
If I try my query with Firefox, by default I have a 400 and a 200 with chrome.
I compare the header and the issue is with the accept-language.
By default, on Chrome, I Have : Accept-Language: fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
On Firefox (Brave, Edge also maybe), I Have : Accept-Language: fr,fr-FR;q=0.8,en-US;q=0.5,en;q=0.3
Please note the inversion between fr-FR and fr.
If I change my Accept-Language on Firefox from fr,fr-FR to FR-fr,fr. It's working.
If I set my Accept-Language to "fr" only, I still have a 400. Work with "Fr-fr".
So after some test, my conclusion is that atlas have an issue with two letter header accept-langage.
So on my TS/JS code, just add accept-language with 4 letters to work again.
xhr.open('GET', url, true);
xhr.setRequestHeader("Accept-Language", this.acceptLanguage);
xhr.send();
My opinion is that it's a server/ atlas issue, I can't imagine this kind of code evolution from Microsoft ^^
The DocuSign documentation goes through an easy to follow authorization flow for code grant. I'm able to get the "code" from the initial GET request to /oath/auth but getting the tokens gives me an error of "invalid_grant" when I try in postman. I've followed the steps and have a request that looks like this using account-d.docusign.com for host:
POST /oauth/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic MjMwNTQ2YTctOWM1NS00MGFkLThmYmYtYWYyMDVkNTQ5NGFkOjMwODc1NTVlLTBhMWMtNGFhOC1iMzI2LTY4MmM3YmYyNzZlOQ==
grant_type=authorization_code&code=ey2dj3nd.AAAA39djasd3.dkn4449d21d
Two other members of my team have also tried with their developer accounts and all are getting invalid_grant errors. Is this no longer supported or are there common errors associated with this error that we might be able to investigate?
Re-check all of your values.
I was also getting the same invalid_grant response and could not figure out why at first. It turns out that I had a typo in the Content-Type header. I was using application/x-www-form-urlencode instead of application/x-www-form-urlencoded.
You may not be, but if you are submitting the exact Authorization Header as you've posted it here in your question (MjMwNTQ2YTctOWM1NS00MGFkLThmYmYtYWYyMDVkNTQ5NGFkOjMwODc1NTVlLTBhMWMtNGFhOC1iMzI2LTY4MmM3YmYyNzZlOQ==) it will fail with that message.
That is the base64 value for the sample integration key and sample secret key provided in their documentation. If you decode that string with an online base64decoder it will result in 230546a7-9c55-40ad-8fbf-af205d5494ad:3087555e-0a1c-4aa8-b326-682c7bf276e9. This is the same sample integration key and secret in the documentation.
Check the Authorization header you are submitting by encoding your integration key and secret (integrationKey:secret) using this online base64encoder. This will make sure the issue isn't with your base64 encoding of your integration key and secret. Once you have that value make sure your Authorization uses the word Basic before the value you got from this website. (Basic base64stringFromOnlineEncoder)
Check that the code your are submitting in the body of the post is not the sample code from their documentation. ey2dj3nd.AAAA39djasd3.dkn4449d21d is the sample code from their documentation. You may just be using that in your question as a placeholder but if you are submitting any of those values it will return invalid_grant. Make sure that the body of your post does not have any leading or trailing spaces.
Have the correct Content-Type set application/x-www-form-urlencoded
Have the correct Authorization header set Basic base64EncodedIntegrationKey:Secret
Have the correct body using the valid code received from the GET request to /oauth/auth with no leading or trailing spaces, making sure you're not using the values from your question.
If you are still having trouble and you are not doing a user application but are doing a service integration you can use Legacy Authentication to get your oAuth2 token.
Alternative Method using Legacy Authentication for Service Integrations
This method does not use a grant code. You pass in the integration key, username and password into the X-DocuSign-Authentication header in JSON format.
Demo Server: demo.docusign.net
Production Server: www.docusign.net API
Version: v2
POST https://{server}/restapi/{apiVersion}/oauth2/token
Content-Type: application/x-www-form-urlencoded
X-DocuSign-Authentication: {"IntegratorKey":"your_integrator_key","Password":"docusign_account_password","Username":"docusign_account_username"}
grant_type=password&client_id=your_integrator_key&username=docusign_account_username&password=docusign_account_password&scope=api
If you are building a user application that requires the user enter their docusign credentials to generate the token, this alternative will not work for you.
For anyone who is facing this error, I'd like to point out this note in the documentation:
Note: The obtained authorization code is only viable for 2 minutes. If more then two minutes pass between obtaining the authorization code and attempting to exchange it for an access token, the operation will fail.
I was struggling with the same error until I spotted the note and sped up my typing to meet the 2 minutes.
Hope it helps someone else.
In my case the problem was related to having set a wrong value for Content-Type header, namely "application/x-www-form-URIencoded" instead of the correct "application/x-www-form-urlencoded". Note though that in my case the problem was not a "typo" but an excessive trust in DocuSign documentation.
Indeed the wrong Content-Type is, at the time of writing, suggested directly into the documentation page where they describe the Authorization Code Grant workflow, see the image below for the relevant part.
Hopefully they will fix the documentation soon but for the time being be careful not to blindly copy & paste the code from their examples without thinking, as I initially did.
anyone have an idea what is wrong here I am getting a BadRequest with the following
{"error":"invalid_grant","error_description":"unauthorized_client"}
var client = new RestClient(ESIGNURL);
var request = new RestRequest("/oauth/token");
request.Method = Method.POST;
request.AddHeader("Content-Type", "application/x-www-form-urlencoded");
request.AddHeader("Authorization", "Basic " + Convert.ToBase64String(System.Text.Encoding.UTF8.GetBytes(integrationkey+ ":" + secret)));
string body = "grant_type=authorization_code&code=" + code;
request.Parameters.Clear();
request.AddParameter("application/x-www-form-urlencoded", body, ParameterType.RequestBody);
var response = client.Execute(request);
I was getting this error as well. What I realized is I was appending the state at the end of the code before passing it to the oauth token endpoint.
This snippet is from Docusign explaining what are some other reasons for getting that error.
Invalid-error explanation
I just spent a day doing this (in NodeJS). I'll add a couple of things to the answers from before. First, I had to put:
"Content-Type": "application/x-www-form-urlencoded"
in the header. Otherwise it gave me the message:
{
"error": "invalid_grant",
"error_description": "unsupported_grant_type"
}
Second, the base64 encoding:
I used this in NodeJS and it worked
const integration_key = process.env.INTEGRATION_KEY;
const secret_key = process.env.SECRET_KEY;
const authinfo =
integration_key.toString("utf8") + ":" + secret_key.toString("utf8");
const buff2 = Buffer(authinfo, "utf8").toString("base64");
If you use "base64url" it dosen't work because it strips the == off of the end of the string. The = symbol is used as padding and apparently it's needed. You see a similar difference on this site https://www.base64encode.org/ when you toggle the url safe encoding option. If you don't have the padding on the end of your base64 encoded string (or if it's generally incorrect) you get this message:
{
"error": "invalid_grant",
"error_description": "unauthorized_client"
}
Finally, if you're using Postman (I'm using DocuSign's Postman Collection) remember to reset and save the codeFromUrl variable after you update it. Otherwise it doesn't update and you get the message:
{
"error": "invalid_grant",
"error_description": "expired_client_token"
}
This means the old URL code has expired and your new one didn't save.
I want to find samples of how to work with Mobile/Web App by sending POST.
Previously in Mobile Services it was possible to send POST like this:
POST /tables/table_name HTTP/1.1
Host: http://arduinounoserver.azure-mobile.net/
X-ZUMO-APPLICATION: YaRWxxxxzKGRxxxxLPiNxxxxXYOvxxxx
{"value": 234}
But now authentication was absolutely changed.
How to do it now and is it possible to find somewhere POST samples?
Have found only Table Service REST API but it's still not clear for me
you can still use next URL notation to access tables:
https://yoursite/tables/tablename
but, you can get an error:
{"error":"An invalid API version was specified in the request, this request needs to specify a ZUMO-API-VERSION of 2.0.0."}
so with Web App Easy Table you should use next ZUMO-header, for example
POST https://vyutest.azurewebsites.net/Tables/Test HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 49
ZUMO-API-VERSION: 2.0.0
Host: vyutest.azurewebsites.net
{"text":"Complete the tutorial","complete":false}
It works.
I am developing SharePoint 2013 Provider hosted app using javascript REST Api. In order to perform create (POST), or update (MERGE) operations on sharepoint items I need to set the 'X-RequestDigest' header with the request.
When in SharePoint-hosted apps I was able to use the http://contoso.sharepoint.com/SharePointHostedApp/_api/contextinfo service to retrieve the request digest value; however, I am having trouble getting that value when in a provider hosted app.
The first difference of provider hosted app is that now we need to make a cross-domain request since we are not running in a sharepoint site, but in a different domain hosted on a different server. To be clear: instead of
$.ajax({
url: appWebUrl + '/_api/contextinfo',
method: "POST",
headers: { "Accept": "application/json; odata=verbose" }
})
I assumed we need to use the SP.RequestExecutor to execute a cross domain request.
When I construct the request it looks like the following (I've changed the actual urls to something fake, but basically we're telling the proxy to use the host web has the target and get the /_api/contextinfo endpoint):
https://contoso-6f921c6addc19f.sharepoint.com/ProviderHostedApp/_api/SP.AppContextSite(#target)/contextinfo?#target=%27https://contoso.sharepoint.com%27
However, I receive this error: Cannot find resource for the request contextinfo. meaning that the endpoint does not exist.
I made sure to use the POST method with the correct application/json;odata=verbose headers with an empty body.
How do I get the request digest value from the /_api/contextinfo service to the provider hosted app?
Based on what I've researched:
We can't use $('#__REQUESTDIGEST').val(); because that is not available to a provider hosted app.
We need to use some from of cross-domain request since I'm running outside of sharepoint.
I have tried setting the target of the cross-domain request to both the hostWebUrl and the appWebUrl and both give the same error.
There must be some way to get this value, otherwise we would only be limited to read operations when using JavaScript. Has anyone else solved this using javascript?
Technically I could try to implement the needed services using the CSOM on server and exposing them using WebAPI or WCF but it seem unreasonable to have to implement that.
UPDATE:
I went ahead and tried adding a WebAPI controller which exposes a service that retrieves the request digest value. This actually does retrieve a request digest value; however, when attempting to use this in the header of future calls I receive the error: "The security validation for this page is invalid and might be corrupted. Please use your web browser's Back button to try your operation again." I'm guessing that the request digest value has some referer header information in it which indicates it was requested by the server; however, the future requests made with it are from the browser, and this mismatch might be an acceptable reason for it be invalid.
Few more notes on the attempt at adding the webAPI controller.
I based my code off of this example: http://code.msdn.microsoft.com/SharePoint-2013-Perform-335d925b but converted it to use the newer HttpClient.
I overloaded the Page_Load method, stored the contextTokenString in a variable that could be accessed by the WebAPI controller then parsed/used it when requesting the contextinfo.
Does anyone know if this is a correct diagnosis of that error? Is there something encoded in the request digest value that would prevent it from be able to be retrieved like I suggested?
I have also opened a related question on the MSDN forums since I'm desperate to find an answer:
http://social.msdn.microsoft.com/Forums/sharepoint/en-US/f601fddd-3747-4152-b2d1-4e89f0a771c4/question-about-limitation-of-providerhosted-apps-is-it-possible-to-make-rest-calls-with-javascript?forum=sharepointdevelopmentprevious
I find it very hard to believe this could be a limitation of provider hosted applications, but given all testing I've done, I'm starting to doubt the viability of provider-hosted applications when you want to write in javascript.
Begging for Help!
I realize you've already answered your own question within the context of a provider-hosted app, but for developers like myself who need to access the REST API from a language not based in the .NET framework, (and who cannot write their project as a web app) I'd like to expand on the subject a bit more. I was tasked with writing an iPad app recently that required this functionality, and ended up reverse-engineering the following:
Step 1 - Authentication
Not going to actually cover this, as there are plenty of examples online that demonstrate the more common methods. The Microsoft.SharePoint.Client libraries mostly seem to use claims-based authentication when working with SharePoint Online, with the token being requested through the endpoint found at: https://login.microsoftonline.com/RST2.srf
Step 2 - Acquiring the Request Digest (Dumb Approach)
If you're feeling lazy, you can always take your authenticated cookies, make a GET request to the homepage of the target web, and use a regular expression like:
/(<input (?:[^>]*?)name="?__REQUESTDIGEST"?(?:[^>]*?)\/>)/i
to scrape the HTML from the response. From there, it'd just be a matter of extracting the value attribute for your digest.
Step 2 - Acquiring the Request Digest (SOAP Approach)
The CSOM libraries currently use a SOAP endpoint when acquiring the request digest it uses for its API calls. You can do the same by making a SOAP request to the $(SPWebUrl)/_vti_bin/sites.asmx web service similar to the following:
POST $(SPWebUrl)/_vti_bin/sites.asmx HTTP/1.1
Content-Type: text/xml
SOAPAction: http://schemas.microsoft.com/sharepoint/soap/GetUpdatedFormDigestInformation
X-RequestForceAuthentication: true
Host: $(SPSiteHostname)
Expect: 100-continue
Accept-Encoding: gzip, deflate
Cookie: $(Authenticated Cookies - Either "FedAuth=...; rtFa=..." or "SPOIDCRL=...")
Content-Length: $(Whatever)
<?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>
When executed successfully, the response body will look something like:
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<GetUpdatedFormDigestInformationResponse xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<GetUpdatedFormDigestInformationResult>
<DigestValue>0x1122334455 ... FF,27 Jul 2015 03:06:54 -0000</DigestValue>
<TimeoutSeconds>1800</TimeoutSeconds>
<WebFullUrl>$(SPWebUrl)</WebFullUrl>
<LibraryVersion>16.0.3208.1222</LibraryVersion>
<SupportedSchemaVersions>14.0.0.0,15.0.0.0</SupportedSchemaVersions>
</GetUpdatedFormDigestInformationResult>
</GetUpdatedFormDigestInformationResponse>
</soap:Body>
</soap:Envelope>
At that point, you can just extract your request digest from the DigestValue block.
Step 2 - Acquiring the Request Digest (REST Approach)
The last approach I'm aware of uses an OData request made to the $(SPWebUrl)/_api/contextinfo endpoint:
POST $(SPWebUrl)/_api/contextinfo HTTP/1.1
Host: $(SPSiteHostname)
DataServiceVersion: 3.0
Accept: application/json; odata=nometadata
Content-Type: application/json; odata=verbose
Cookie: $(Authenticated Cookies)
Content-Length: 2
{}
When executed successfully, the response body will look like the following:
{
"FormDigestTimeoutSeconds" : 1800,
"FormDigestValue" : "0x1122334455 ... FF,27 Jul 2015 03:06:54 -0000",
"LibraryVersion" : "16.0.4230.1217",
"SiteFullUrl" : "$(SPSiteUrl)",
"SupportedSchemaVersions" : ["14.0.0.0", "15.0.0.0"],
"WebFullUrl" : "$(SPWebUrl)"
}
The request digest can then be extracted from the FormDigestValue property.
Step 2 - Acquiring the Request Digest (CSOM Approach)
If you're using CSOM, you have functionality for dealing with this built-in. (probably JSOM, too, unless it uses the __REQUESTDIGEST input) Microsoft.SharePoint.Client.ClientContext uses the SOAP approach internally to manage its request digest and publicly exposes this functionality through its GetFormDigestDirect method.
ClientContext clientContext = new ClientContext(webUrl);
// ...
FormDigestInfo formDigest = clientContext.GetFormDigestDirect();
// X-RequestDigest header value
string headerValue = formDigest.DigestValue;
// Digest expiration
DateTime expirationDate = formDigest.Expiration;
Usage Notes: While ClientContext maintains and reuses a cached form digest for its requests, this method does not give you access to that cached value. Instead, this method requests a brand new form digest with each call, so you'll want to setup your own caching mechanism in order to re-use unexpired digests across multiple requests.
Step 2 - Acquiring the Request Digest (JSOM Approach)
If you're using the JSOM API and don't have access to a __REQUESTDIGEST input value, you can access the ClientContext's cached digest with the following extensions. (Thanks to bdimag for pointing out the cache)
Step 3 - Acquiring New Request Digests
Assuming you use the request digest before the TimeoutSeconds have elapsed, a valid REST request made like the following:
POST $(SPWebUrl)/_api/web/lists/getByTitle('MyList')/getchanges HTTP/1.1
Host: $(SPSiteHostname)
DataServiceVersion: 3.0
Accept: application/json; odata=nometadata
Content-Type: application/json; odata=verbose
X-RequestDigest: $(Request Digest)
Cookie: $(Authenticated Cookies)
Content-Length: 140
{
"query" : {
"__metadata" : {
"type" : "SP.ChangeQuery"
},
"Add" : "True",
"Item" : "True",
"Update" : "True"
}
}
should result in a successful response. If you inspect the headers of that response, you'll find something like:
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: application/json;odata=fullmetadata;streaming=true;charset=utf-8
...
X-RequestDigest: 0xAABBCC...00,03 Sep 2014 18:09:34 -0000
...
Extracting the X-RequestDigest response header will allow you to use it in a subsequent call. (I'm guessing that the timeout starts over from the time of your new response + $(TimeoutSeconds) from the original digest request, but I've yet to confirm)
Unfortunately, the X-RequestDigest header is only returned by REST requests that actually require a request digest. You will not receive the header for requests where a request digest is unrequired, such as: $(SPWebUrl)/_api/web/lists/getByTitle('MyList')/items. Should you find yourself needing a new digest after the original has timed out, you'll need to make another request to the $(SPWebUrl)/_vti_bin/sites.asmx web service.
Step ??? - Handling Errors
A few example responses from when our requests fail:
The following response comes from a REST request made to the $(SPWebUrl)/_api/contextinfo endpoint. (no authentication cookies specified)
HTTP/1.1 403 Forbidden
Cache-Control: private, max-age=0
Content-Type: application/json;odata=nometadata;charset=utf-8
...
Server: Microsoft-IIS/8.5
X-SharePointHealthScore: 0
X-Forms_Based_Auth_Required: $(SPRootSiteUrl)/_forms/default.aspx?ReturnUrl=/_layouts/15/error.aspx&Source=%2f_vti_bin%2fclient.svc%2fcontextinfo
X-Forms_Based_Auth_Return_Url: $(SPRootSiteUrl)/_layouts/15/error.aspx
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
X-IDCRL_AUTH_PARAMS_V1: IDCRL Type="BPOSIDCRL", EndPoint="$(SiteRelativeUrl)/_vti_bin/idcrl.svc/", RootDomain="sharepoint.com", Policy="MBI"
...
Date: Wed, 12 Aug 2015 02:27:35 GMT
Content-Length: 201
{
"odata.error" : {
"code" : "-2147024891, System.UnauthorizedAccessException",
"message" : {
"lang" : "en-US",
"value" : "Access denied. You do not have permission to perform this action or access this resource."
}
}
}
Next, a response originating from a REST request made with an expired request digest (Note the X-RequestDigest header specified in the response.. Not sure if that's usable, but it's worth a shot):
HTTP/1.1 403 FORBIDDEN
Cache-Control: private, max-age=0
Content-Type: application/json;odata=fullmetadata;charset=utf-8
...
Server: Microsoft-IIS/8.5
Set-Cookie: rtFa=$(RtfaAuthCookie)
Set-Cookie: FedAuth=$(FedAuth)
X-SharePointHealthScore: 0
X-RequestDigest: 0x19EFFF80617AB2E48B0A9FF0ABA1440B5301E7445F3859177771BF6A39C7E4A74643108D862505A2C99350B0EDB871EF3DDE960BB68060601268818027F04956,12 Aug 2015 02:39:22 -0000
DATASERVICEVERSION: 3.0
X-AspNet-Version: 4.0.30319
...
Date: Wed, 12 Aug 2015 02:39:22 GMT
Content-Length: 253
{
"odata.error" : {
"code" : "-2130575251, Microsoft.SharePoint.SPException",
"message" : {
"lang" : "en-US",
"value" : "The security validation for this page is invalid and might be corrupted. Please use your web browser's Back button to try your operation again."
}
}
}
Ok, I made a fresh provider hosted application to re-test the problem.
You can view the repository here:
https://github.com/mattmazzola/providerhosted_01
After comparing this new application and the old one, I realized I had a misunderstanding of how the SP.RequestExecutor expected urls to be constructed. I thought it was required to use the SP.AppContextSite() endpoint.
I was incorrectly constructing a request to the appWeb with a url similar to the following:
https://contoso-6f921c6addc19f.sharepoint.com/ProviderHostedApp/_api/SP.AppContextSite(#target)/contextinfo?#target=%27https%3A%2F%2Fcontoso-6f921c6addc19f.sharepoint.com%2FProviderHostedApp%27
As you can see, the #target was set to the appWeb url but infact when making request to the appWeb using RequestExecutor you do no need to do this. It is simply appweburl + "/_api/contextinfo". It is only when making requests for resources existing on the hostWeb that you need use the AppContextSite and set the #target.
You can see the full code in the linked solution for more details. I have added a screenshot of the solution.
You mus remember that in permissions level exist a check that disable all service under _api
_api/web/lists
_api/search/query?querytext=’SharePoint’
_api/SP.UserProfiles.PeopleManager
You enable that ensure
site settings->site permissions->permissions level->read->
Integration client features
Use remote interface
I found the solution in
https://letrasandnumeros.com/2017/02/28/unauthorizedaccessexception-sharepoint-_api/
The RequestExecutor actually takes care of the RequestDigest for you. You don't have to get it.
If for some reason, you still want to get the RequestDigest value, try doing the call without changing the context site.
It seems possible to inject javascript in a get request, when refering to the /xsp/.ibmmodres/ XSP/Domino resources.
Normally, when you try this at .nsf/ resources, you get a correct default or custom errorpage without XSS possibilities. Special characters are substituted.
Example:
- http://[server]/[path]/[dbname].nsf/%3Cscript%3Ealert%28document.cookie%29%3C/script%3E
Result:
HTTP Web Server: Cannot find design element
But refering to the /xsp/.ibmmodres/ resources, it yields XSS possibilities.
Example:
http://[server]/[path]/[dbname].nsf/xsp/.ibmmodres/%3Cscript%3Ealert%28document.cookie%29%3C/script%3E
Result:
I get a 404 errorpage "Cannot load unregistered resource /"
And it executes CSJS and shows for example DomAuthSessID !!
How is this possible?
Is there a way to avoid this?
Please help!
Here is an article about how to avoid this:
http://www.wissel.net/blog/d6plinks/SHWL-8XS3MY
Check your Domino version. It should be fixed in 8.5.3. FP2 (not fully sure about that) (but definitely 9.0 Beta).
Other than that follow my instructions and create some web rules:
Type of rule: HTTP response headers
Incoming URL pattern: */xsp/.ibmxspres/*
HTTP response codes: 404
Expires header: Don't add header
Custom header: Content-Type : text/plain (overwrite)
Type of rule: HTTP response headers
Incoming URL pattern: */xsp/.ibmmodres/*
HTTP response codes: 404
Expires header: Don't add header
Custom header: Content-Type : text/plain (overwrite)