REST API Posting two request simultaneously with different properties fails with 403 status code due to CSRF check - json

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...

Related

Apps script: SumUp api requests giving error 400

I am integrating online payments to a web app. To do this I am using the SumUp API. It takes simple http requests. Here is the part of the documentation I am working with: https://developer.sumup.com/docs/single-payment/
My initial request for an access token from the API works fine. But issues arise when creating a checkout resource. I have checked many times and my JSON appears to be correct. The values all appear fine too. However when I run the code the SumUp server returns me this:
Request failed for https://api.sumup.com returned code 400. Truncated server response: {"error":"Unexpected token a in JSON at position 0"}
Here is my code:
var pay_headers = {
"Authorization": `Bearer ${access_token}`,
"Content-Type": "application/json"
};
var pay_details = {
"checkout_reference": "SH8Q0B5C", //random string of letters and numbers
"amount":10,
"currency":"GBP",
"pay_to_email": "docuser#sumup.com",
"description":"Sample one-time payment"
};
var pay_options = {
"method": "post",
"headers": pay_headers,
"payload": pay_details
};
var pay_response = UrlFetchApp.fetch("https://api.sumup.com/v0.1/checkouts",pay_options).getContentText();
Is there something wrong with this? I would appreciate any help as this has been a problematic issue. Thanks
The final 403 error here is due to a poorly documented requirement on the Sumup API. Basically you have to request that your account (whether test or live) is granted scope for the payments part of the API.
If you don't have this you can get an access token but will then be served a 403 error when creating a Checkout.
Save yourself some time and follow this: (I didn't)
https://github.com/sumup/sumup-ecom-php-sdk/issues/24
i.e. email integration#sumup.com
API docs:
https://developer.sumup.com/docs/authorization/#authorization-scopes
When I saw your provided document, the sample curl is as follows. Ref
curl -X POST \
https://api.sumup.com/v0.1/checkouts \
-H 'Authorization: Bearer 565e2d19cef68203170ddadb952141326d14e03f4ccbd46daa079c26c910a864' \
-H 'Content-Type: application/json' \
-d '{
"checkout_reference": "CO746453",
"amount": 10,
"currency": "EUR",
"pay_to_email": "docuser#sumup.com",
"description": "Sample one-time payment"
}'
If this curl command is converted to Google Apps Script, how about modifying your script as follows?
From:
"payload": pay_details
To:
"payload": JSON.stringify(pay_details)
Note:
When the above modification is reflected to your script, when an error occurs, can you provide the error message?
Added:
When above modification is reflected to your script, the request is the same with the sample curl command. From your following reply,
The thing is with the previous API request made in the script (the one that fetches the access token) the payload works fine without using stringify. I did try it for this payload however and it gave me a 403 forbidden. Here is the error message: Exception: Request failed for https://api.sumup.com returned code 403. Truncated server response: {"error_message":"request_not_allowed","error_code":"FORBIDDEN","status_code":403}. This error can be replicated by removing various other parts of the request too so I'm not sure whether it is beneficial to use stringify...
If your access token and your request body are valid values, from 403 of the status code, I'm worried that in your situation, the access from Google side might not be able to be done.
Reference:
403 Forbidden

Getting an incomplete (chunked) JSON response on Angular proxy

While developing an Angular 7 web app, I am using the proxy.conf.json file and --proxy-config option on the ng serve command to proxy my requests from https://localhost:4200/api to a remote url which hosts the actual REST API.
When doing an HTTP GET request directly to the remote url through my browser (Chrome) or Postman, I always get the full JSON response like I expect it to be.
When requesting this on the angular proxy url, I get only a part of the JSON response (most of the time - not always).
I am aware that the API returns response header Transfer-encoding 'chunked' and from what I understand, this means having to process the response as a stream.
One way to avoid this, is to let the API return a Content-Length header. But I'd rather want to leave the API unchanged.
I read that when proxying on an nginx server, there is an option 'proxy_buffering' to configure how to handle large HTTP responses. But I'm using the built-in angular proxy (which is a webpack dev server) and I haven't found a way to configure such property.
proxy.conf.json
...
"/api/messages": {
"target": "http://myRemoteHost:myRemotePort/myRemoteContext/v1/",
"secure": false,
"changeOrigin": true,
"logLevel": "debug",
"pathRewrite": {
"^/api": ""
}
},
...
messages.service.ts
return this.http.get<Message[]>(this.endpoint, {params: httpParams});
Error in console
Error Code: 200
Message: Http failure during parsing for http://...
HttpErrorResponse:
error: SyntaxError: Unexpected end of JSON input at JSON.parse (<anonymous>)
at XMLHttpRequest.onLoad (https://localhost:4200/hal/vendor.js:32570:51)
at ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (https://localhost:4200/hal/polyfills.js:2768:31)
at Object.onInvokeTask (https://localhost:4200/hal/vendor.js:78088:33) at ZoneDelegate.push../node_modules/zone.js/dist/zone.js.ZoneDelegate.invokeTask (https://localhost:4200/hal/polyfills.js:2767:60)
at Zone.push../node_modules/zone.js/dist/zone.js.Zone.runTask (https://localhost:4200/hal/polyfills.js:2540:47)
at ZoneTask.push../node_modules/zone.js/dist/zone.js.ZoneTask.invokeTask [as invoke] (https://localhost:4200/hal/polyfills.js:2843:34)
at invokeTask (https://localhost:4200/hal/polyfills.js:4089:14)
at XMLHttpRequest.globalZoneAwareCallback (https://localhost:4200/hal/polyfills.js:4126:21)
message: "Unexpected end of JSON input"
I was expecting that when using the standard HttpClient from Angular, I always would get the full response (also for large HTTP responses). This does not seem to be the case. My gut feeling says the proxy is causing this.
So do I need to specifically change my code in order to process chunked http responses?
Or is this (hopefully configurable) behaviour from the webpack server?
Does anyone know a possible solution?
One way to avoid this, is to let the API return a Content-Length header. But I'd rather want to leave the API unchanged.
This worked for us, our customers had proxy servers for security, and 25% of our JSON requests were broken because Transfer-Encoding was chunked. We had to remove compression for the time being.
Thank you kind stranger for posting this question.
I had a similar problem using angular 6 and running the local server (with ng --serve) with node.js 8.10.
I resolved it by upgrading node.js to 12.13.0
Got around this by adding
"headers": {
"Connection": "keep-alive"
}
inside the proxy item declaration in proxy.conf.json, as follows:
"/api/messages": {
"target": "http://myRemoteHost:myRemotePort/myRemoteContext/v1/",
"secure": false,
"changeOrigin": true,
"logLevel": "debug",
"headers": {
"Connection": "keep-alive"
}
}
Adding this, I managed to retrieve quite large datasets without the JSON response getting cut off.
Hope this can help someone, this has been haunting me for the past few days.

NetSuite RESTlet NLAuth using Postman

I'm new in NetSuite and I tried to make a REST request using Postman I've write in header the NLAuth authorization like the line above:
Authorization : NLAuth nlauth_account=0000000, nlauth_email=at#at.com, nlauth_signature=mypassworld,nlauth_role=3
And i follow the process of this tutorial: https://community.boomi.com/docs/DOC-2676#jive_content_id_To_call_the_getRecord_RESTlet
But I receive the following response:
{
"error": {
"code": "INVALID_LOGIN_ATTEMPT",
"message": "Invalid login attempt."
}
}
Use Postman's built-in Authorization tools to build the correct OAuth1 header: https://www.getpostman.com/docs/v6/postman/sending_api_requests/authorization
It's best practice to use OAuth so credentials are not exposed. NS uses OAuth 1.0.
Realm = NS Account number
Signature Method can be SHA1 or SHA256
Make sure the "Add params to header" is checked.
Always "Update Request" before sending in order to generate proper Nonce/Timestamp
Add the Content-Type = application/json to the headers
Body must be a valid JSON object.
I've used the following doc and it help me: If the URL above don't work click in this link.
URL https://system.xx.netsuite.com/app/help/helpcenter.nl?fid=section_1530099787.html

Why is my ajax get request responding with an error even though it was successful?

I am attempting to retrieve some data from a 3rd party domain. When I enter the request url. I am able to see the data I requested. But when I attempt to make a call using ajax (to a different domain), it returns the error message. Why am I not able to retrieve the data? Might it have something to do with cross-domain policy and not using jsonp? Here is my code:
<script>
$(document).ready(function() {
$.ajax ({
type: 'GET',
url: 'https://crm.zoho.com/crm/private/json/Potentials/searchRecords?authtoken=xxx&scope=crmapi&criteria=(((Potential%20Email:test2#email.com))&selectColumns=Potentials(Potential%20Name)&fromIndex=1&toIndex=1',
dataType: 'json',
success: function(test) {
alert(JSON.stringify(test));
},
error: function(test) {
alert(JSON.stringify(test));
}
});
});
</script>
Because the request that you has send is blocked by the browser. When you perform a request using an object XmlHttpRequest and obviously javascript, the browser applied cross-domain policy, defined in WC3, and thus verify in url the origin and target domain (protocol, host and port), if those elements are in different domain (i.e. host and port), then the request never comes out from browser (a.k.a User Agent). You can use jsonp to "break" or "jump" this policy, simply is a tag "script" with a resource (src) defined in a different domain using a parameter called "jsonCallback=?" added in query string, who really receives the data in format json. This is more ugly and have a security risk, therefore never be used.
The other method is to use and enable a "technique" (is more than that) known like "CORS" (Cross Origin Request Sharing), where the client (browser) and server (resource at different domain), send, exchange and negotiate an Http Headers to secure that who send and who received are authorized to exchange information. The basics steps to realize CORS is:
Explicity define in client (ajax-jquery) that CORS will be used in request, specifying CrossDomain:true. This will enable HTTP Headers defined in CORS
Specify in the HTTP Server, a HTTP Header indicating the Domain Source that have permissions to call a resource hosted in server. The most general header can be defined like: Access-Control-Allow-Origin , with value asigned a domain, like "*" (all domain authorized) (Access-Control-Allow-Origin, *)
In some Browsers, sometimes they send a http header request called "preflight request", is like a discover via to know if the server is prepared to recieve cross-origin request. This Http Header contains a "Method HTTP" value or "Verb HTTP" (like PUT,POST,GET,DELETE) assigned to "OPTIONS", then the server must be configured too to recieve HTTP Headers with Method "OPTIONS", and therefore allow methods http like PUT, DELETE,POST or GET. In generals terms the server must have this headers when in the request had a method HTTP "OPTIONS":
Access-Control-Allow-Methods , "POST, PUT, DELETE, GET, OPTIONS"
Access-Control-Allow-Headers, ", "Content-Type, Accept"
Finally, the client (ajax) will recieve the data from the server.
This sounds a little confusing and the steps are few, sorry that not put a code like examples, but, really CORS is not hard to understand.
I hope this will help.
References from Mozilla:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
This show what is CORS and you can use in configuration server:
http://enable-cors.org/

FIWARE-Lab KeyRock Access Token Request error

I'm testing the Authorization Code Grant protocol on the instance of KeyRock GE at FIWARE-Lab using DHC web client.
So far I have succeeded on implementing the Authorization Request, and I obtain the code to be used on the Access Token Request. The URL for the Authorization Request is the following (although not executed on DHC, but on a regular browser so I can introduce my user and password):
https://account.lab.fiware.org/oauth2/authorize/?response_type=code&client_id=2122&redirect_uri=http%3A%2F%2Flocalhost%2FCallback
I have checked that the client_id and the redirect_uri are both correct against the values related with my application at my account at FIWARE-Lab.
Executing the following request (can't post images, so I'll describe)
POST
https:// account.lab.fiware.org/oauth2/token?grant_type=authorization_code&code=<code>&redirect_uri=http%3A%2F%2Flocalhost%2FCallback -- <code> is the code obtained on the Auth. Request
Authorization: Basic <XXXX> --- <XXXX> is the result of base64(client_id+":"+client_secret)
Content-Type: application/x-www-form-urlencoded
...I get the following error message:
{
"error":{
"message": "create_access_token() takes exactly 3 arguments (2 given)",
"code": 400,
"title": "Bad Request"
}
}
I've checked the authorization is correct (Basic using the OAuth credentials from my application), and I'm using the same redirect_uri used at the previous Authorization Request, and the code obtained from it.
¿What is wrong?
P.S.: If I remove any or all of the query parameters, I still get the same error
Don't pass the parameters in the url. Instead, add them to request's body as query string:
POST /oauth2/token HTTP/1.1
Host: account.lab.fiware.org
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <XXXX> --- <XXXX>
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=1234&redirect_uri=http%3A%2F%2Flocalhost%3A9000%2Fcodecallback.html
I suggest to follow the steps in the presentation:
Adding Identity Management and Access Control to your Application
It gives you details about what are the different requests that you have to follow and also what are the expected response of them.