The problem occurring while we are consuming ZOHO analytics dashboard api endpoint with long workspace titles trimmed with (...) if it reaches 50 characters. Actually Zoho workspace support titles up to 50 characters only so we are also passing the names in same way for example on Zoho workspace title is like xyz... from API end point we do same thing xyz... in request.
But it started throwing 7103 error all of sudden. We are not getting any good help from ZOHO support as well.
Below is the API endpoint format where I am getting the issue. It's mainly due to the (...):
{Method: POST, RequestUri: 'https://xyz/api/TestIQ Schedule 8 Inventory Management And Re.../TestIQ Schedule 8 Inventory Management And Re...', Version: 1.1, Content: System.Net.Http.StringContent, Headers:
{
Authorization: Zoho-oauthtoken 1001.7878787878787878787856.656huh6767.6767
Content-Type: text/plain; charset=utf-8
}}
On ZOHO workspace the name is created: TestIQ Schedule 8 Inventory Management And Re....
The application has live users who are getting impacted due to this.
Related
I am using Dataverse via the Web API to access data from a server. This works very well in itself. All unlocked tables/entities can be accessed via the corresponding URL using GET method and also return valid results. That means the access and the authentication via security token works.
However, when I call the POST-Method to exactly the same table/entity, I get an error message back:
__checkpoint ⇢ 401 UNAUTHORIZED from POST https://ANONYM.crm4.dynamics.com/api/data/v9.2/
The role assigned to the application user actually has explicit write permissions to the table.
The post looks like this:
POST /api/data/v9.2/ANONYMtime-acquisitions HTTP/1.1
user-agent: ReactorNetty/1.1.2
host: ANONYM.crm4.dynamics.com
ACCEPT: */*
content-type: application/json
content-length: 282
{"cr2a0_id":0,"cr2a0_Abweichung":7.5,"cr2a0_Datum":"Sat Feb 01 00:00:00 CET 2020","cr2a0_Ist-
Arbeitszeit":7.5,"cr2a0_Mitarbeiter":"ANONYM","cr2a0_Pause":0. 0,"cr2a0_Soll-
Arbeitszeit":0.0,"cr2a0_Wochentag":"ANONYM","cr2a0_Beginn":"09:00","cr2a0_Ende":"16:30",
"cr2a0_Info":""}
I would have expected that the writing access also works. What else could be the reason for this?
I tried to reproduce the same in my environment and got the same error like below:
I created an Azure AD Application and added API permission:
I generated the auth-code by using below endpoint:
https://login.microsoftonline.com/TenantID/oauth2/v2.0/authorize?
&client_id=ClientID
&response_type=code
&redirect_uri=redirectUri
&response_mode=query
&scope=https://admin.services.crm.dynamics.com/user_impersonation
&state=12345
I generated the access token by using below parameters:
GET https://login.microsoftonline.com/TenantID/oauth2/v2.0/token
client_id:ClientID
client_secret:ClientSecret
scope:https://admin.services.crm.dynamics.com/user_impersonation
grant_type:authorization_code
redirect_uri:redirectURi
code:code
By using the above access token I am able to make the GET request successfully as below:
If still the issue occurs, make sure to assign Security role like below:
And check the version of the CRM like below:
To make a POST query, refer the below blog:
Dynamics CRM 365 WEB API Common Errors and Resolution – xrm CRM Dynamics by Bipin Kumar
I've setup two business developer applications (test & prod environments) to handle Facebook Login and posting an image to a group directly via a web app. The endpoint I'm using is the following:
https://graph.facebook.com/v14.0/{group-id}/photos?access_token={access_token}
I followed this documentation: https://developers.facebook.com/.../refer.../page/photos/...
with a POST request and Content-Type: multipart/form-data.
The request payload looks like the following:
-----------------------------41883366036964688284103242839
Content-Disposition: form-data; name="source"; filename="blob"
Content-Type: image/png
�PNG
{a bunch of alphanumeric chars........}
-----------------------------41883366036964688284103242839
Content-Disposition: form-data; name="caption"
{the caption of the image}
-----------------------------41883366036964688284103242839--
The test environment works flawlessly: I build the picture in javascript and then call the api endpoint against a test facebook group.
On the production environment, the VERY SAME call with the very same image returns the error:
"Please reduce the amount of data you're asking for, then retry your request"
The post actually makes his way on the Facebook group but without the image.
I tried putting the limit=1 param with no luck.
I tried "cross-posting" with the Facebook PROD app to the Facebook TEST group and it works, so it seems the problem is posting to the PROD Facebook group.
In the image below what I see in the browser when the request fails, it seems the image size is below the 4Mb limit given by Facebook. Is there a better way to check the size of the image I'm trying to send?
However, if the image is the same, how come in one group I get to post correctly and in the other I don't?
How can I overcome this?
When making a GET request (through Postman) at "https://api.agora.io/beta/analytics/call/lists" with query parameters:
appid (following the official documentation, i base64 encoded {Customer ID}:{Customer Secret} string)
start_ts (timestamp format e.g. 1627990383)
end_ts (timestamp format e.g. 1628163183)
When I make the request, i get a response with status 200 OK, but the response body is the following :
{
"code": 500,
"message": "Unknown error"
}
I set the headers as mentioned in the official documentation :
Has anyone got a legit response from this request? And what was his request construction?
I have the same problem. I asked the support what to do, this is what they answered me:
The analytics restful API you are trying to use is part of the
Enterprise support package and requires that for you to be able to use
them. We do have something in the works for cheaper analytics later
down on the line so if you do want to purchase a package for restful
APIs for analytics, please let us know and we can put you in contact
with a CSM.
I think this functionality is supported only in the Enterprise version of the package.
I am trying to connect my React app to the Jira Cloud API and can't seem to get past a 403 error.
My code currently does a Auth dance using OAuth 2.0 and returns the token and cloudid. I can use this to GET issues, however POST request (like creating an issue) return with 403. I have found here that this error is returned if the user does not have the necessary permission to access the resource or run the method.
I have ensured the user has the correct scope ([write: jira-work, read: jira-work]) and verified this is reflected in the user account (in their account > connect apps tab).
My app is not linked (via ApplicationLink) or installed (via Apps, Manage Apps), is this necessary to perform POST requests?
Here is a sample of my code:
fetch(`https://api.atlassian.com/ex/jira/${jira.cloudid}/rest/api/2/issue/`, {
method: "POST",
headers: {
"Content-Type": 'application/json',
"Authorization": `Bearer ${jira.token}`
},
body: JSON.stringify(data)
})
.then(...)
Neither api version 2 or 3 are working for this POST request. I have explored using Basic Auth however this fails due to CORS errors.
I have verified that the POST request does work in POSTMAN (using the cloudid and token).
---------------------------------------------------------------------------------------------------------------------------
UPDATE
After talking to Atlassian Staff, there is an issue within their API security:
"By trying the same thing you mentioned I think I found what the problem is. Your request likely fails with a ‘XSRF check failed’ in the browser.
I’ve already talked to one of our security engineers and we quickly dived into the implementation code to confirm why this not working and what would need to be changed on our side. We’ve also already opened a engineering ticket to get this addressed. This will likely take a few weeks to get addressed, but I’ll keep you posted if I hear any updates!"
The XSRF check failed was the main error for my 403 response. I'll post any updates I receive and answer the question when a resolution is found.
This has apparently been resolved. Follow the discussion here: https://community.developer.atlassian.com/t/jira-cloud-rest-api-oauth-2-0-error-403-on-post-requests/25621/4
I'm following the Tutorial "Manage product entitlements from a service" here,
Am getting stuck on step 3, where calls to request an access token return a 404 error.
Step1: In Azure Portal,
Created new WebApp, gave it a name & accepted all the defaults.
Selected the default AD directory and registered the app (used the
APP URL as the login URL).
Grabbed the AP ID _APP_ID_ and created app key _APP_SECRET_.
Updated manifest, replaced identifierURIs as described.
"identifierUris" : [
"https://onestore.microsoft.com",
"https://onestore.microsoft.com/b2b/keys/create/collections",
"https://onestore.microsoft.com/b2b/keys/create/purchase"
],
Step2: In MS DevCenter
Added _APP_ID_ to "Services-> Product collections and purchases -> Client ID".
Step3: Testing using Postman
I pulled the Azure AD Tenant ID _TENANT_ID_ from the PortalDiagnostics.json.
Using the provided sample, I used postman to post as follows:
POST https://login.microsoftonline.com/_TENANT_ID_/oauth2/token HTTP/1.1
Host: login.microsoftonline.com
Content-Type: application/x-www-form-urlencoded; charset=utf-8
grant_type=client_credentials
&client_id=_APP_ID_
&client_secret=_APP_SECRET_
&resource=https://onestore.microsoft.com
Host and content type are set in the headers, remainder is posted as raw text in the body.
POSTMAN with headers & body
POSTMAN headers
POSTMAN body
As you can see, the result is a 404 with no body, making this a little tough to trouble shoot.
Question:
Have I missed something obvious in steps 1 & 2?
Should I be able to test this with POSTMAN?
I'd appreciate any pointers; I can't find any other tutorials to cross reference.
So in this case the problem was a rogue HTTP/1.1 at the end of the URL + some unencoded content in the form data. Using Postman's x-www-form-urlencoded tab helped for that since it encodes all the fields for you.