We are using the API of Active Collab v5, which works quite good.
Unfortunately, we are not able to attach a successfully uploaded file to an existing task. We tried several different ways, but never suceeded.
The one way we believe should work, is shown here:
PUT https://<DOMAIN>/api/v1/projects/<PROJECTID>/tasks/<TASKID>
Accept: */*
X-Angie-AuthApiToken: <TOKEN>
Content-Type: text/plain
Accept-Language: en-us
Accept-Encoding: gzip, deflate
{
"attach_uploaded_files": [
"<CODE>"
]
}
Content-Type: application/json; charset=utf-8
X-Angie-ApplicationVersion: 5.11.23
Pragma: no-cache
Server: Apache
Content-Encoding: gzip
Vary: Accept-Encoding
{"single":{"id":<TASKID>,"class":"Task","url_path":"\/projects\/<PROJECTID>\/ tasks\/
<TASKID>","name":"<TASKNAME>","assignee_id":0,"delegated_by_id":0,
" completed_on":null,"completed_by_id":null,"is_completed":false,"comments_count": 0,
"attachments":[],"labels":[],"is_trashed":false,"trashed_on":null," trashed_by_id":0,
"project_id":<PROJECTID>,"is_hidden_from_clients":false,"body":"<BODYTEXT >",
"body_formatted":"<BODYTEXT>","created_on":1481044542,"created_by_id":20,
" updated_on":1481052449,"updated_by_id":20,"task_number":258,"task_list_id":<TLID> ,
"position":17,"is_important":false,"start_on":null,"due_on":null,"estimate":0,
" job_type_id":0,"total_subtasks":0,"completed_subtasks":0,"open_subtasks":0,
" created_from_recurring_task_id":0},"subscribers":[20],"comments":[],"reminders": [],
"subtasks":[],"task_list":{"id":<TLID>,"class":"TaskList",
"url_path":"\/ projects\/<PROJECTID>\/task-lists\/<TLID>","name":"Inbox",
"is_trashed":false,"trashed_on": null,"trashed_by_id":0,"completed_on":null,
"completed_by_id":null,"is_completed" :false,"project_id":8,"created_on":1480605343,
"created_by_id":20,"updated_on": 1481052420,"updated_by_id":20,"start_on":null,
"due_on":null,"position":1," open_tasks":1,"completed_tasks":44},"tracked_time":0,
"tracked_expenses":0}
We always get a 200 OK, but the file remains unattached.
Can someone please tell us what we are doing wrong?
Thank you for your support and best regards.
Lukas.
Everything looks fine except the "Content-Type" header of your request.
Since you are sending a JSON encoded body to the API you need to set the request header to
"Content-type: application/json; charset=utf-8".
cheers
Nick
Related
I have a WCF service which I make API requests to.
This API call returns a JSON response object and also is able to return it in GZIP compression as well when "gzip" value is used in "Accept-Encoding" header.
The problem is when I try to get the response in GZIP, Postman shows "Could not get any response" although I see response and response's content are OK (200 status code) in Fiddler and can easily decompress the response content in my C# client.
I took a look in Postman Console but all I see is "Error: incorrect header check".
I hardly tried to find any documentation regarding this header check but couldn't find any.
These are the request headers:
POST /correction/v1/document?lang=US HTTP/1.1
Content-Type: text/plain
Accept-Encoding: gzip
User-Agent: PostmanRuntime/7.6.0
Accept: */*
content-length: 630
Connection: close
These are the response headers:
HTTP/1.1 200 OK
Content-Length: 512
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Server: Microsoft-HTTPAPI/2.0
Date: Sun, 24 Feb 2019 14:05:50 GMT
Connection: close
The only thing I suspect is wrong is this message from Fiddler:
I integrated this code into mine in order to use GZIP in WCF.
https://github.com/carlosfigueira/WCFSamples/tree/master/MessageEncoder/GZipEncoderAndAutoFormatSelection
Basically, it captures the response before returning to client and use GZipStream for compression.
I got the same issue, I added the following header to fix this issue.
Accept-Encoding : *
I was able to solve a similar issue by using the header Accept-Encoding: */* or if you want to be specific do Accept-Encoding: */* that way the HTTP client will be able to process the response based on the type of encoding received, in the case of a gzip, it will decode the response and show it as normal text.
For me, I removed 'Accept-Encoding' in the request header.
I got this issue when the REST service was returning a zip content (aka. WinZip format). I solved the error by compressing the data using 7zip to produce true gzip format.
I am using RestSharp to upload multi-part messages (basically, form data with a file attached at the end). The receiving service seems to require that I specify the Content-Transfer-Encoding header on each part or I get a 400 error on the POST.
I can't find any way in RestSharp to set this, or to specify "headers" that are actually inside the body of the parts. What I need to produce is a payload that looks like this:
POST http://server/object/create HTTP/1.1
User-Agent: RestSharp/105.2.3.0
Content-Type: multipart/form-data; boundary=-----------------------------28947758029299
Host: server:8080
Content-Length: 540
-------------------------------28947758029299
Content-Type: application/xml;charset=US-ASCII
Content-Disposition: form-data; name="form"
Content-Transfer-Encoding: 8bit
<form>this is some form data in XML format</form>
-------------------------------28947758029299
Content-Disposition: form-data; name="1.eml"; filename="1.email"
Content-Type: application/octet-stream; charset=ISO-8859-1
Content-Transfer-Encoding: binary
This is arbitrary file content to attach to the form.
-------------------------------28947758029299--
So far, this is what I've got (I'm prototyping in PowerShell but the results are identical in C#):
$request = New-Object RestSharp.RestRequest("iss", [RestSharp.Method]::POST)
$request.AddParameter("application/xml;charset=UTF-8", $form, [RestSharp.ParameterType]::RequestBody) | Out-Null
$request.AddFile("att.txt", "C:\Development\att.txt", "application/octet-stream; charset=ISO-8859-1") | Out-Null
$response = $rest.Execute($request)
which does everything I need except the Content-Transfer-Encoding part.
Is this possible with RestSharp, or should I drop down to use the HTTP client directly?
Hi I'm trying to do a SQL injection in a login form.
With BurpSuite I intercept the request:
POST /xxxx/web/Login HTTP/1.1
Host: 10.0.0.70:42020
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:49.0) Gecko/20100101 Firefox/49.0
Accept: application/json, text/plain, */*
Accept-Language: it-IT,it;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/json
Referer: http://xxxxxx.com/xxxxxx/
Content-Length: 44
origin: http://xxxxx.com
Connection: close
{"username”:"user",”password”:"pass"}
using:
sqlmap -u requestFile
(where requestFile is the content of the request intercepted with Burp)
sqlmap can't find the injectable field that is password.
I'm sure that's it's injectable cause if as password I input:
' OR 1=1; -- -
I can login with every username I insert
Tried also with:
{"username”:*,”password”:*}
but no luck.
What I'm doing wrong?
Example:
POST / HTTP/1.1
Host: www.example.com
{"username":"*", "password":"*"}
Saved as sqlrequest.txt
Can then initiate a test using this command:
py sqlmap.py -r sqlrequest.txt --level=5 risk=3 --force-ssl
You should then receive a prompt that a custom injection marker is found and that JSON data found in POST body. Process both and then you are good to go.
Sources:
https://security.stackexchange.com/a/150506/67046
https://security.stackexchange.com/a/51862/67046
sqlmap -u URL
sqlmap -r requestFile
Tutorial on how to use request
check this video
I am intercepting HTTP request/response from an Adobe Shockwave-based web music player application using Chrome Dev tools. When I click the Play button on music player, HTTP request headers like following are raised:
POST /some_url HTTP/1.1
Host: something.com
Connection: keep-alive
Content-Length: 103
Origin: http://something.com
X-Requested-With: ShockwaveFlash/22
User-Agent: Mozilla
Content-Type: application/x-www-form-urlencoded
Accept: */*
Referer: http://something.com/player.swf
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
And Form data looks like following:
param1=561a0d9452069h76fhg46h67a599e8gy34nlj=
param2=something
Now, is there any way to know from where this param1=561a0d9452069h76fhg46h67a599e8gy34nlj= form data came from and how it is generated? If it's some kind of encrypted string or a token, how this is done?
Thank you for your answers
The HTTP request would have come from a URLRequest in ActionScript, which passes the data in key/value pairs. You could have a look at using SWFWire Inspector to decompile the code.
Is it possible to send gzip'd HTTP POST requests in Paw?
I have accept-encoding, content-encoding set to gzip but it seems to be not enough to get it to work.
POST / HTTP/1.1
Content-Type: application/json
Content-Encoding: gzip
Accept: application/json
Accept-Encoding: gzip
X-Protocol-Version: 2
User-Agent: test-ua
Host: host123:8080
Connection: close
Content-Length: 120
[{"user-id":"123","p-id":"1"}]
I can confirm that. It is not possible at the moment to send gzip'ed body automatically.
If you use "Content-Encoding: gzip" you must gzip the body and drop the file into Paw. Paw is sending the gzip'ed body without any issue. I am using Paw version 2.2.5.
I think you need to gzip the body yourself and then paste it in. I could be wrong and if so would love this auto gzip feature!