So I was trying to use the LinkedIn Developer API to post some text with a image or multiple images at once.
So here's the issue
https://learn.microsoft.com/en-gb/linkedin/consumer/integrations/self-serve/share-on-linkedin
This is the DOCS for the share on LinkedIn that is completely working fine when am posting just text.
But the issue arises when I try to create Post with Image
https://api.linkedin.com/v2/assets?action=registerUpload This API is giving me an error like this.
{
"serviceErrorCode": 65600,
"message": "Invalid access token",
"status": 401
}
Even I refreshed the token to check if there was an issue with my token. My access token is working fine with sharing the text-only post.
If your above API works fine in case then you are registered for uploading file. Then you'll receive the below URL from the response. But they mentioned it with CURL and I want to send a cross-origin request from Axios. I tried a curl converter but that doesn't explain how we will upload the file with the request.
curl -i --upload-file /Users/peter/Desktop/superneatimage.png --header "Authorization: Bearer redacted" 'https://api.linkedin.com/mediaUpload/C5522AQGTYER3k3ByHQ/feedshare-uploadedImage/0?ca=vector_feedshare&cn=uploads&m=AQJbrN86Zm265gAAAWemyz2pxPSgONtBiZdchrgG872QltnfYjnMdb2j3A&app=1953784&sync=0&v=beta&ut=2H-IhpbfXrRow1'
I have the file either in URL or in Base64 format. I don't have a binary file present in my case. Well, I want to send a binary file too for a default case but for most requests, I'll be using the URL for the image.
Thanks for reading the whole question. Please help me with the information you have that can be useful for me.
I'm trying to download a file provided by a Wordpress plugin Pinpoint World. This plugin uses admin-ajax.php to retrieve that file in admin UI.
I want to periodically download it for backup. How can I download it using curl? It looks like it needs to authenticate the request using cookies (as the browser does while inspecting the requests). Anyway I can simulate that using curl in bash?
The following results in 400 Bad Request:
curl "https://${HOST}/wp-admin/admin-ajax.php" \
--data-raw 'action=dopbsp_reservations_get&type=xls&calendar_id=1&start_date=&end_date=&start_hour=00%3A00&end_hour=23%3A59&status_pending=false&status_approved=false&status_rejected=false&status_canceled=false&status_expired=false&payment_methods=&search=&page=1&per_page=25&order=ASC&order_by=check_in' \
-o /tmp/output.xls
Basic authentication (using --user) didn't work either.
How can I authenticate to wordpress' admin-ajax, using bash?
You can just pass the cookie from your authenticated logged-in user on your curl request
First, login to your wordpress site on your browser.
Then hit F12 and go to application tab, then cookies
then copy the cookies that looks like wordpress_logged_in_xxxxxxxxxxxx
then you can use it on your curl request
example to run basic test,
create a simple ajax request which return a user object if your request is authenticated. otherwise, it will return null
add_action( 'wp_ajax_sample_duh', 'sample_duh');
add_action( 'wp_ajax_nopriv_sample_duh', 'sample_duh');
function sample_duh() {
wp_send_json([
'user' => wp_get_current_user()
]);
}
run your curl request with the cookies you copied from the browser.
e.g.
curl -X POST --cookie "wordpress_logged_in_xxxxxxxxxxxxxx=xxxxxxxxxxx" http://mydomain.me/wp-admin/admin-ajax.php?action=sample_duh
You should get the user object in your response if you have a valid cookie,
then use the same cookie with your actual curl request
every now and then I come to this question, google around for some time without getting a definitive answer and let it be.
Problem:
I want to update an existing resource, but the logic how this update works is on the backend side.
Let's assume a product should only be visible for a set time. Keeping it simple. The time "from" is stored in the database along the product data: product.visibleFromDate and the duration (eg. 30 days) is just a variable or configured somewhere (not in DB).
Now I want to call the backend telling it to update the visibleFromDate to "now": /api/product/:id/updatevisibility
In this case I don't want to send a body because the server should determine what value "now" really is.
I actually don't really care if the server answers with the updated resource or no content.
HTTP Request
GET
Should not be used because it should be idempotent, which it wouldn't be because the visibleFromDate would be updated
POST
Don't want to send the date from frontend
PUT
Don't want to send the date from frontend + should be idempotent
PATCH
Merge Patch: Don't want to send the date from frontend
JSON Patch: Again, I don't want to send a value, I want the backend to determine it.
Of course I could just send an empty object, the whole resource or some nonsense and ignore it on the backend side, but still I feel like I am missing this "trigger" type of requests which only need the type of resource, id and action.
Depending on the mutability of the data it should either be POST(immutable) or PATCH(mutable). It doesn't depend on what You're sending or not sending.
If You really want to do it by the book then you should send a '{}' when there are no fields to send. If any is added later you will just add it like '{"duration":"30"}'
You would definitely want POST over GET for authorization/authentication purposes.
You don't need to have a body for a POST request. Your endpoint will just listen for a request, it will extract :id, and then run your time update function.
PUT and PATCH are semantic equivalents to POST. Unless you programmed the backend to differentiate them, there won't be any difference. You don't even need them at all.
A single empty-body POST will be enough for your endpoint. But you may consider using empty-body PATCH just as a meaningful endpoint. In both cases, your backend will extract the :id and then just run the same function (after auth* if any)
EDIT: Seems not all people can grasp what I have, so here are a working nodejs/express backend and curl requests to use. you don't need a request body, and all behave the same, except semantics and security over GET.
this is the server code:
const express = require('express');
const app = express();
const port = 3000
const updatetime = async (id)=>{
let newdate=Date.now();
console.log(`updating resource ${id} to have a new date ${newdate}`);
return Promise.resolve("done")
}
const processrequest=async (req, res) => {
console.log(req.method);
console.log(req.headers);
console.log(req.headers.authorization);
console.log(req.body)
console.log(req.params)
try{
let result=await updatetime(req.params.id);
console.log(result);
res.status(200).send("time updated")
}catch{
res.status(500).send("something went wrong")
}
}
app.get( '/:id/updatetime', (req, res) => processrequest(req,res))
app.post( '/:id/updatetime', (req, res) => processrequest(req,res))
app.put( '/:id/updatetime', (req, res) => processrequest(req,res))
app.patch('/:id/updatetime', (req, res) => processrequest(req,res))
app.listen(port, () => {
console.log(`listening on port ${port}`)
})
test all endpoint without a body, all works because magic:
curl -X GET -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
curl -X POST -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
curl -X PUT -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
curl -X PATCH -H "Authorization: Basic" localhost:3000/123qwe/updatetime
time updated
server output for all request types are the same because it is just a magic(!) that is developers' choice of implementation:
listening on port 3000
GET/POST/PUt/PATCH
{
host: 'localhost:3000',
'user-agent': 'curl/7.78.0',
accept: '*/*',
authorization: 'Basic'
}
Basic
undefined
{ id: '123qwe' }
updating resource 123qwe to have a new date 1656495470330
done
You are not required to pass a body in a request (Although the specification says so), PATCH will be your best option here since semantically it is updating an “part of existing resource” while PUT is meant for "updating the entire resource".
my other answer did not satisfy you, so i will try the same but from a different viewpoint.
you are data engineer:
you don't retrieve any data with this operation, so no GET.
you operate on already-existing data, so no POST.
you don't change the whole data, so no PUT.
you are partially changing the data, see, you just use PATCH for the operation.
you will send an empty body {} to be consistent
you are an operational backend engineer.
GET is still considered to be used to retrieve a resource.
you want to run a function on the server which will partially modify the resource having the id given as the parameter in the url, so just use a POST request. it is like calling a function in your programming language.
or try PATCH to get the sympathy of your users.
or use PUT to get their anger when they realized what happens.
it is already getting the id from the URL, so you don't have to send any body unless your frontend API forces. curl won't send a body if you don't give one, for example.
semantics are not hard-coded rules. they are there to guide you and keep you in the line as much as possible. the problem is that they don't have solid implementation details. they are also "opinions" of a group of people which has pretty fine shape anyone can accept.
PS: It is said, "POST can be used on an already-existing data to append". sure it is, but the question in scope asks about changing a field, not creating a new one.
I'm using "curl -L --post302 -request PUT --data-binary #file " to post a file to a redirected address. At the moment the redirection is not optional since it will allow for signed headers and a new destination. The GET version works well. The PUT version under a certain file size threshold works also. I need a way for the PUT to allow itself to be redirected without sending the file on the first request (to the redirectorURL) and then only send the file when the POST is redirected to a new URL. In other words, I don't want to transfer the same file twice. Is this possible? According to the RFC (https://www.rfc-editor.org/rfc/rfc2616#section-8.2) it appears that a server may send a 100 "with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests without the client asking to send its payload" so what I'm asking for may be thwarted by the server. Is there a way around this with one curl call? If not, two curl calls?
Try curl -L -T file $URL as the more "proper" way to PUT that file. (Often repeated by me: -X and --request should be avoided if possible, they cause misery.)
curl will use "Expect: 100" by itself in this case, but you'll also probably learn that servers widely don't care about supporting that anyway so it'll most likely still end up having to PUT twice...
I am trying to submit a HTTP POST request into a web server that runs IIS.
curl -X POST -d
but I am getting an HTML page definition in return.
I have looked and didn't find any match, your support will be appreciated.