I am attempting to use the GoCardless API sandbox to create a customer but only get a 403 forbidden error
{"error": {
"message": "Forbidden request",
"errors": [ {
"reason": "forbidden",
"message": "Forbidden request"
}],
"documentation_url": "https://developer.gocardless.com/api-reference#forbidden",
"type": "invalid_api_usage",
"request_id": "8b870491-e8ca-436c-a602-bb613bba7d96",
"code": 403
}}
I have used OAuth to get a bearer token which I am using for my post to the sandbox url
https://api-sandbox.gocardless.com/customers
Using this url and the bearer token i can get customers and update a customer that i created manually via the sandbox client portal. If i purposefully make the token an invalid value i get a 401 error instead so I am sure the token is correct.
The documentation for the error type "invalid_api_usage" is as follows
This is an error with the request you made. It could be an invalid
URL, the authentication header could be missing, invalid, or grant
insufficient permissions, you may have reached your rate limit, or the
syntax of your request could be incorrect. The errors will give more
detail of the specific issue.
The fact i can update a customer i believe crosses most of those potential issues of that list.
I am now using the exact post body content of the GoCardless API example for creating customer to verify the syntax should be correct.
{
"customers": {
"email": "user#example.com",
"given_name": "Frank",
"family_name": "Osborne",
"address_line1": "27 Acer Road",
"address_line2": "Apt 2",
"city": "London",
"postal_code": "E8 3GX",
"country_code": "GB",
"metadata": {
"salesforce_id": "ABCD1234"
}
}
}
I am running these requests from SoapUI instead of my application so I can be sure I am sending exactly what i am expecting to send.
From the API documentation I understand my application must have approved payment pages to create customers in the live environment however this is prefixed by a statement that this is not restricted in the sandbox environment.
Restrictions
Whilst the entire GoCardless API is accessible in the sandbox
environment, the following restrictions exist in live.
Payment page restrictions
Unless your payment pages have been approved as scheme rules compliant
by our sponsor bank you must use the Redirect Flow API to create
customers, bank accounts and mandates.
The following endpoints are therefore restricted:
Customers: Create
Customer bank accounts: Create
Mandate: Create, Reinstate
Javascript flow: All endpoints
It seems to me the 403 forbidden response is exactly what i would be getting if Create Customer was restricted in the sandbox environment however the API documentation explicitly states that this is not the case.
My question is basically what could I be doing wrong? Maybe somebody can spot something I have forgotten or am misunderstanding.
The answer is that the sandbox is restricted in the same way as the live environment.
The API documentation appears to be worded in a way that suggest the sandbox is unrestricted however this is not the case.
To remove the restriction in the sandbox environment you need to contact GoCardless support and request it.
Related
I want to retrieve data regarding insights of my Facebook posts. I am able to retrieve all this information under graph API explorer but keep on getting errors the moment I put it into a graph URL.
Here is the URL :
https://graph.facebook.com/v15.0/{page_id}/posts?fields=insights.metric(post_engaged_users,page_posts_impressions_unique)&token_access=ACCESS_TOKEN
(I removed the page_id and ACCESS_TOKEN for privacy.)
I end up getting this error:
{
"error": {
"message": "(#200) Provide valid app ID",
"type": "OAuthException",
"code": 200,
"fbtrace_id": "AuaCwwoNGZW_U4Ivay4Xi1f"
}
}
Can someone guide me on what to do in this case? I guess I have to include my app_ID into the Graph API URL, but where exactly?
Thank you.
I searched for a solution from the Facebook developer community but could not get any solutions.
Which one is best for Rest API response ?
In here I return some meta information with actual data. Although I am not sure they need to use those meta information or not.
{
"version": "1.0.0",
"isError": false,
"statusCode": 200,
"message": "Permission Object",
"data": {
"id": 1,
"name": "user create",
"created_at": "2022-11-30T10:18:20.000000Z"
}
}
In second example I am returning only the relevant data.
{
"id": 1,
"name": "user create",
"created_at": "2022-11-30T10:18:20.000000Z"
}
Give me suggestion if there are other better way.
I noticed you've used the tag REST, so I assume you are thinking about a RESTful API implementation and have some knowledge about RESTful API design.
If you need some best practices, a couple of them I think are useful. here and here.
Looking at your examples, I would prefer the second option, the reasons are:
IsError can be determined by the HTTP response, e.g. 400, 500, 200, 201, so it's redundant.
Status and Message are also redundant when the response is successful but could be useful in an error state, like in ASP.NET, you can use the ProblemDetails response (you can customize the way you want).
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
"title": "Unable to create a new user due to missing name",
"status": 400,
"traceId": "00-0aa7d64ad154a1e1853c413a0def982d-195d3558c90f7876-00"
}
version is an interesting one. Usually, it can be included in the request header or URL. If the API cannot handle the version requested, then it should return an error in the problem details.
Thus, I prefer the second option and send a problem details response when there is an error.
An open source CRM with more than 18K start on github uses Laravel-default api resource
Project Link
Code Example link
Pay attention to status codes
Reference
This one is super important. If there's one thing you need to remember from this article, this is probably it:
The worst thing your API could do is return an error response with a
200 OK status code.
It's simply bad semantics. Instead, return a meaningful status code that correctly describes the type of error.
Still, you might wonder, "But I'm sending error details in the response body as you recommended, so what's wrong with that?"
Let me tell you a story.
I once had to use an API that returned 200 OK for every response and indicated whether the request had succeeded via a status field:
{
"status": "success",
"data": {}
}
So even though the status was 200 OK, I could not be absolutely sure it didn't fail to process my request.
This kind of design is a real no-no because it breaks the trust between the API and their users. You come to fear that the API could be lying to you.
All of this is extremely un-RESTful. What should you do instead?
Make use of the status code and only use the response body to provide error details.
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error": "Expected at least two items in list."
}
JSON API is a format that works with HTTP. It delineates how clients should request or edit data from a server, and how the server should respond to said requests.
Google Contacts allows us to bypass Etag verification by passing * instead of the contact's current Etag for Edit/Delete requests.
Google Contacts API documentation
Note: The special Etag value * can be used to bypass this verification and process the update regardless of updates from other clients.
Is there any similar way to bypass the Etag verification for edit/delete in People API?
Facing the following error if the etag value is not sent in Person object during update. The value " * " is also not working in People API.
Request:
{
"emailAddresses": [
{
"displayName": "test1#gmail.com",
"value": "test1#gmail.com",
"type": "home"
}
]
}
Response:
{
"error": {
"code": 400,
"message": "Request must set person.etag or person.metadata.sources.etag for the source that is being updated.",
"status": "INVALID_ARGUMENT"
}
}
You have to send the resource name in both the delete and the update requests.
Delete request only requires resource name.
Update request requires the resource name and the person. IMO the best way to update is to fetch the Person first then update the data then push it back.
updateMask is also required if you are not using one of their APIs
https://developers.google.com/people/api/rest/v1/people/updateContact?hl=en
See https://developers.google.com/people/api/rest/v1/people/updateContact?hl=en
The server returns a 400 error with reason "failedPrecondition" if person.metadata.sources.etag is different than the contact's etag, which indicates the contact has changed since its data was read. Clients should get the latest person and merge their updates into the latest person.
In short, you maybe out of luck using just the *
I'm sending two post requests using the REST API: http://localhost:8111/app/rest/buildQueue but my second request fails with
403 Forbidden: Responding with 403 status code due to failed CSRF check: no "Origin" header is present and no authentication provided with the request, consider adding "Origin: http://localhost:8111" header.
I'm wondering why is this happening since if I run the build in the UI and change the params ex. build1 has %version=2% and build2 has %version=3% it will run parallel with each other running on different available agents.
Here's my json request:
REST API endpoint: http://localhost:8111/app/rest/buildQueue
JSON body:
{
"branchName": "master",
"buildType": {
"id": "DockerBuild",
"projectId": "Test"
},
"properties": {
"property": [
{
"name": "DOCKER_IMAGE_NAME",
"value": "test-3"
},
{
"name": "SNAPSHOT_DEPENDENCY_VERSION",
"value": "0.6"
}
]
}
}
Am I missing a parameter to be able to run builds in parallel with each other?
When you face problems regarding CSRF protection in TeamCity (for example, you get the "Responding with 403 status code due to failed CSRF check" response from the server), you can follow these steps:
If you use a reverse proxy, make sure you correctly configure Host/Origin headers, as described above. In the meantime, you may want to add the public URL of your server to CORS-enabled origins.
You can temporary disable CSRF protection at all by setting the teamcity.csrf.origin.check.enabled=logOnly internal property.
Information about failed CSRF attempts are logged into TeamCity/logs/teamcity-auth.log files. For more detailed diagnostics of the requests, enable debug-auth logging preset.
Try pass in the request header -H 'Origin: http://localhost:8111'
Maybe this can be useful for someone, I got the same error with a single POST using Postman:
403 Forbidden: Responding with 403 status code due to failed CSRF check: no "Origin" header is present and no authentication provided with the request, consider adding "Origin: http://teamcity:20011" header.
So I followed the recommendation of the error message, and in Header I added "Origin" with the value "http://teamcity:20011" and that fixed the issue. BTW, in Authorization I selected "Bearer Token" and I pasted the token generated previously through TeamCity. This is the call:
http://teamcity:20011/app/rest/buildQueue
I was just testing how to trigger a build using the API and it worked successfully. Now the following step is to implement this call using JavaScript.
Request a CSRF header with the appropriate request:
https://teamcity/authenticationTest.html?csrf
and set it in the "X-TC-CSRF-TOKEN" header of your POST request
If you specify an Access Token to the request header like Authorization: Bearer ..., you don't need to specify a CSRF token, and what you should actually check is if you're not sending Cookies.
This is from the developer in JetBrains:
If you're using a token-based authentication, there should be no need to provide CSRF token header and obtain it with authenticationTest.html call.
In this scenario, it is expected that there are no session Cookies in the HTTP request (otherwise, TeamCity will try to find a token).
I.e. basically, you should be able to do the HTTP call in no-session way by providing the Authorization: Bearer {{token}} header only.
https://youtrack.jetbrains.com/issue/TW-69566/Flaky-builds-with-CSRF-Header-X-TC-CSRF-Token-does-not-match-CSRF-session-value#focus=Comments-27-4644138.0-0
Well, the error and the documentation don't seem to explain this, though...
My current project, a restful API, validates a POST request to create a new user and multiple errors could occur (with HTTP status):
username not set (400 BadRequest)
username is taken (409 Conflict)
server can't establish db connection (500 Internal Server Error)
...
Should I immediatly send back a JSON response like this
{
"status": 400,
"Message": "No username is set"
}
if an error was detected or should is it better if I accumulate all errors like here:
{
"status": <HTTP STATUS CODE>,
"errors": [
{"message": "Username is not set."},
{"message": "Can't access the database."}
]
}
The last approach would not require multiple request to send a valid payload. But which status code should be used, if the username is not set (400 Bad Request) or the server can't access the database (500 Internal Server Error)?
I think if you foresee the need for multiple errors in one request, then the second JSON (with the multiple errors) is preferred. Another benefit of doing the multiple errors response is that as a user of your service, if i get back multiple errors, I can address them all at one shot, instead of addressing them one at a time as I get them.
After some research, the best (most standard) way to respond is a JSON structure of this form:
{
"error": {
"code": "400",
"message": "main error message here",
"target": "approx what the error came from",
"details": [
{
"code": "23-098a",
"message": "Disk drive has frozen up again. It needs to be replaced",
"target": "not sure what the target is"
}
],
"innererror": {
"trace": [ ... ],
"context": [ ... ]
}
}
}
The multiple errors you want to place would be individual elements in the "details" array. Using this structure you would still need some overall summary of the error, however the details would contain as many individual error messages as you want.
This is the format proposed by the OASIS data standard OASIS OData and seems to be the most standard option out there, however there does not seem to be high adoption rates of any standard at this point.
This also conforms to the JSON RPC 2.0 Spec as it requires that the error be an object in a "error" member, and that you have a code and message.
You can find the complete open source library that implements this at: Mendocino JSON Utilities. This library supports the JSON Objects as well as the exceptions.
The details are discussed in my blog post on Error Handling in JSON REST API