I have been using curl & Postman on Chrome to send http POST requests with one variable to an simple HTTP server I have running and I have noticed that they construct the requests slightly differently. Apologies if I might have used any incorrect terminology in constructing the question - I'm still learning this stuff.
Using Postman, the request is constructed by putting a '?' between the resource name and the variable. E.g.
http://192.168.0.2:9999/1/command?a=b
However, the following curl command:
curl -X POST http://192.168.0.2:9999/1/command --data a=b
does not put a '?' between the resource name and the variable.
The result is that the HTTP server interprets the requests differently.
In the first case, the body of the request is empty and in the second case the body contains a=b.
Which version is correct?
Constructing curl , python request , using HTTP POST
Open postman client and click on code [Below save button ] refer snapshot .
when click on code another window appears . refer snapshot .
similarly you can generate various other request [curl , python ,java , php ] refer snapshot
You can refer below link
http://jmeterblogb.blogspot.in/2016/11/constructing-curl-from-python-http-php.html
POST requests post data as part of the request body and GET requests via URL parameters. If you choose the form data option in postman you can pass it the same way (request body) in postman as well. How are parameters sent in an HTTP POST request? may be worth reading.
Related
When running my own mediawiki on localhost I run into a problem with the api endpoint for editing a page. The api works fine otherwise. For instance when querying tokens I get the following output:
$ curl "http://localhost/api.php?action=query&meta=tokens&type=createaccount|csrf|login&format=json"
{"batchcomplete":"","query":{"tokens":{"createaccounttoken":"1e5c2ce3f9e12fdab05a0e6e6352da3162644214+\\","csrftoken":"+\\","logintoken":"35ee2e6ccbbd654bcfada9cddab07f7662634214+\\"}}}
Interestingly the csrftoken has the strange value '+\\', which also seems to be appended to the logintoken.
When posting an edit action (for an existing page called Alice) with this token I get the reponse that the token is missing from the post body. But it's not missing, or is it?
$ curl -X POST "http://localhost/api.php?action=edit&title=Alice&summary=test&text=article&baserevid=0&token=+\\&format=json"
{"error":{"code":"mustpostparams","info":"The following parameter was found in the query string, but must be in the POST body: token.","*":"See http://localhost/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes."}}
Then I followed this advice and added the cookie-jar option to make the curl request from the same session, but it gave the same error response. Any ideas?
By the way I used the docker.io/bitnami/mediawiki:1 docker image together with a mariadb to set up my mediawiki.
The following parameter was found in the query string, but must be in the POST body
I'm not very familiar with curl but it seems that you are sending a post request with the params in the query part. Try sending them in the post body as the error suggests:
curl --data "action=edit&title=Alice&summary=test&text=article&baserevid=0&token=+\\&format=json" http://localhost/api.php
How can I run a flow from another flow in Twilio Studio Flow?
Help with defining the To and From HTTP parameters:
I am a beginner in programming so I am failing to understand the brief notes given in support docs, namely specifying HTTP additional parameters for "To" and "From".
Additional details from comment:
I am trying to run REST API triggered Flow B from primary Flow A by using an http request widget in Flow A in the format below: (as suggested in a similar problem posted on this portal) Widget: HTTP Request [ACCOUNT_SID:AUTH_TOKEN#studio.twilio.com/v1/Flows/THE_OTHER_STUDIO_FLOW_SID/Executions][2] Content Type: Form URL Encoded KEY:VALUES To:+1234567890 From:+2773123456 I am getting error 401. I tried to swap the To number with the From number without success
There are 2 ways you can trigger one twilio studio flow from another
Method 1:
Use the TwiML Redirect Widget. Place the widget where you need it and specify the target studio flow URL there. Studio URLs have the following format
https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid}
Method 2:
Do the same as above programmatically. You can send twilio a twiML response such as the one below
let twiml = new Twilio.twiml.VoiceResponse();
if (something) {
twiml.redirect({
method: 'POST'
}, 'https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid1}');
} else {
twiml.redirect({
method: 'POST'
}, 'https://webhooks.twilio.com/v1/Accounts/{AccountSid}/Flows/{FlowSid2}');
}
For more info, check out https://www.twilio.com/docs/voice/twiml/redirect
Assuming you are not trying to bridge the call between the two flows, this should be possible. To simplify:
You have a call come in on Flow A ("Incoming Call" trigger on Flow A).
Flow A executes its logic.
That logic triggers Flow B by calling its REST API endpoint so that it makes a new outbound call ("REST API" trigger on Flow B).
This last thing is the hard part. Make sure you are looking at the docs for the REST API Execution resource. To trigger a new flow, you need to make a POST request which supplies the To and From parameters.
If you are a beginner at programming, it might be helpful for you to start with a separate HTTP client like Postman to start to get familiar with the structure of an HTTP request, and learn the full extent of what is required to successfully make this API request before you start trying to cram it into Studio and automate it.
That said, this request should be possible to do within the Studio Make HTTP Request widget. If you make your content type Application/JSON, you can pass the To/From parameters directly in a JSON-formatted request body, like this:
{
"To": "+19995551234",
"From": "+12345556789"
}
To be perfectly honest, I don't know what the widget means by "Http Parameters". This could be HTTP Headers, URI parameters, or something else. I think the JSON form is clearer.
I came across the same situation. The solution for authentication is to change the url to include AccountSid and AuthToken
https://[AccountSid]:[AuthToken]#studio.twilio.com/v2/Flows/[SID]/Executions
Instead of Application / Json, use Form Parameters. Then add individual parameters below, for To, From, and Parameters​ (JSON string) for other variables.
This suggests it does :
https://youtube-eng.googleblog.com/2009/10/oembed-support_9.html
But I'm getting nothing back when I do, say
curl "https://www.youtube.com/oembed" -d 'format=json' -d 'url=https://www.youtube.com/watch?v=uXBDgLglFig'
Does anyone know if the oembed API has been deprecated?
You're making a POST request with those options you're passing to curl. You need to make a GET request instead, like so:
curl 'https://www.youtube.com/oembed?format=json&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DuXBDgLglFig'
Note that the URL parameter must be URL encoded. How you do that depends on what language you're using to make the request.
Apparently I was under the misconception that GET and POST methods differ in the sense that the query parameters are put in plaintext as a part of the URL in GET method and the query parameters are THERE IN THE URL IN ENCODED(ENCRYPTED) FORM .
However , I realize that this was a grave misconception . And after going through :
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9
and after writing a simple socket server in python and sending it both GET and POST (through form submission) and printing the request in server side
I got to know that only in GET the parameters are there in the URL but in POST the parameters are there in the request body .
I went through the following question as well so as to see if there is any difference in sending a GET and POST at lower level (C-Level) :
Simple C example of doing an HTTP POST and consuming the response
So as in the above question above I saw that there is no special encryption being applied to the POST request .
As such I would like to confirm the following :
1.The insecurities associated with GET and POST are only because of the GET method attaching the parameters in the URL .
For somebody who can have the whole request body , both the GET and POST methods are equally vulnerable .
Over the network , both the GET and POST body are sent with the equal degree of encryption applied to them .
Looking forward to comments and explanations.
Yes. The server only gets to know about the URL the user entered/clicked on because it's sent as the data of the request, after (transport) security has been negotiated so it's not inherently insecure:
you type into a browser: https://myhost.com/a.page?param=value
browser does DNS lookup of myhost.com
browser connects to https port 443 of retrieved ip
browser negotiates security, possibly including myhost.com if the server is using SNI certificates
connection is now encrypted, browser sends request data over the link:
GET /a.page?param=value HTTP/1.1
Host: my host.com
(other headers)
//Probably no body data
---- or ----
POST /a.page HTTP/1.1
Host: my host.com
(other headers)
param=value //body data
You can see it's all just data sent over an encrypted connection, the headers and the body are separated by a blank line. A GET doesn't have to have a body but is not prevented from having one. A POST usually has a body, but the point I'm making is that the data sent (param=value) that is relevant to the request (the stuff the user typed in, potentially sensitive info) is included somewhere in the request - either in the headers or the body - but all of it is encrypted
The only real difference from a security perspective is that the browser history tends to retain the full URL and hence in the case of a GET request would show param=value in the history to the next person reading it. The data in transit is secure for either GET or POST, but the tendency to put sensitive data on a POST centres on the "data at rest" concept in the context of the client browser's history. If the browser kept no history (and the address bar didn't show the parameters to shoulder surfers) then either method would be approximately equivalent to the other
Securing the connection between browser and server is quite simple and then means the existing send/receive data facilities all work without individual attention, but it's by no means the only way of securing connection. It would be conceivably possibly not to have the transport do it but instead for the server to send a piece of JavaScript and a public part of a public/private key pair on the page somewhere, then every request the page [script causes the browser to] makes could have its data individually encrypted and even though an interim observer could see most of the request, the data could be secured that way. It is only decryptable by the server because the server retains the private part of the key pair
So I just understood that the Slack Web API does not support JSON data over POST. Which means I have to encode my complex and nested JSON object to fit in query parameters over GET. Problem is, the attachements don't seem to work. Does anyone have a solution ?
So I just understood that the Slack Web API does not support JSON data over POST. Which means I have to encode my complex and nested JSON object to fit in query parameters over GET.
I'm not sure I follow what you mean. You can certainly use POST. The body of a Slack API call should be form-encoded, but parameter values are sometimes JSON (as is the case for attachments).
Here's a working curl command that uses HTTP POST to post a message with a simple attachment.
$ curl -d token=<REDACTED> -d channel=<REDACTED> \
-d text="This is the main text." \
-d attachments='[{"text": "This is an attachment."}]' \
https://slack.com/api/chat.postMessage
I'd recommend using POST, but GET also works fine. If you fill in the values in https://api.slack.com/methods/chat.postMessage/test, the tool will give you a URL at the bottom that you can use with HTTP GET.