All I'm trying is to to get a link for sharing the uploaded file.
I send the POST request to this URL:
api.dropbox.com/1/shares/auto/my_text_file.txt?all_the_oauth1_stuff...
But I always receive the 401 not authorized error.
I'm kinda following the documentation, so could anyone explain what I might be doing wrong?
The problem was occurring because of the wrong encoding of the file name (which worked for download / upload scenarios)
Related
I've created a pipeline trigger in Gitlab as the documentation said, but when I open it I get a "error": "404 Not Found".
Webhook URL: https://gitlab.com/api/v4/projects/xxxx/ref/xxxx/trigger/pipeline?token=xxxx
xxxx is being replaced by the values I have. Tried different things, setting the project to public. Enabling/disabling Limit CI_JOB_TOKEN acces.
I'm a bit lost right now.
As examples show you need to use http POST method
curl -X POST $WEBHOOK_URL
If you are pasting the URL directly to your browser it will use http GET and result in 404 error.
The feature that you are referencing in the question might not be working due to a GitLab bug that was introduced in 12.0.0. Please see the issue here: https://gitlab.com/gitlab-org/gitlab/-/issues/30486
I'm trying to translate some CURL code on postman to upload a file on a server.
I have a key called "file" which is the file I want to upload.
On postman, when I pass him the file path, it doesn't work (the api rejects me).
On the other hand, when I tell postman that I want to send him a "file" and that I select the file, it works.
Why does it work when I select the file from postman and why doesn't it work when I pass him the path to my file on my computer?
When I give the path to the file (it doesn't work)
When I select the file from postman (it works)
Postman must be doing something in the background that I do not know and do not know ... And I need to know what it is doing so I can use it in my application
Thanks for your attention and your help ! :)
yes you are right postman does that internally.
https://i.stack.imgur.com/bWs6a.png
here you are passing the file path as string but we need to send the file data
https://i.stack.imgur.com/cGg1r.png
here as you pick a File instead of text postman know that you have entered the file path from there postman read that's file and sends the whole file data
for more understanding, you can check code snippets of different languages
NodeJs - Axios
var data = new FormData();
data.append('file', fs.createReadStream('/Users/filename.txt'));
Well, I found the answer, not using the curl ^^
My provider who developed this CURL script explained me that it was old and unusable today.
So I use a sftp server.
Thanks for your answers I have read them :)
I'm currently working on testing my API via Postman and I've noticed that when I send a post request to the endpoint it will successfully send, yet the same POST request will return a "422 Unprocessable entity" error when run as a collection. The 422 error is puzzling to me because syntactically everything checks out. I'm having a hard time understanding what may be the issue here between running the request as a collection versus without doing so, any thoughts on what the issue might be here?
The reason why a request with an attached file fails when run as a collection is probably the location of the attachment. Files uploaded through form-data must be placed in the working directory. Otherwise, the collection runner won't locate them and will send a request with no files attached. This results in 422. It's different from executing individual requests where files can be placed inside any directory.
This issue is also present in newman and can be similarly solved by specifying a working directory with --working-dir and placing files inside of that directory.
Using dropbox '/media' API call I've obtained a direct https file link. Something like this:
https://dl.dropboxusercontent.com/1/view/asdfasdfasdfasd/file.ext
Then I've changed it from 'https' to 'http' and successfully downloaded the file. Obviously enough, the modified link looked like this:
http://dl.dropboxusercontent.com/1/view/asdfasdfasdfasd/file.ext
My question is wether it's ok to use http links or not? Is it some sort of dropbox bug or a hack?
Strange. I get a 400 error when I try to do the same thing.
Even if HTTP is working for you, I'd advise against using it. Someone eavesdropping on your traffic could learn the link to the file, and it's also possible for someone to impersonate dropboxusercontent.com and send you the wrong data.
It's probably best to stick with HTTPS.
I've been looking for this answer and the other pages didn't help me.
I'm trying to use the google drive api for php. I am trying to test on my local environment and receive this error.
Error: redirect_uri_mismatch
The redirect URI in the request: urn:ietf:wg:oauth:2.0:oob did not match a registered redirect URI
Request Details
scope=https://www.googleapis.com/auth/drive
response_type=code
redirect_uri=urn:ietf:wg:oauth:2.0:oob
access_type=offline
display=page
prompt=consent
client_id=735129338633-0epug8n80jsg0t50ijn7our4a661nnk6.apps.googleusercontent.com
Here is the page for the api:
The url is in
localhost:8888/Spreadsheets/driver.php
What am I doing wrong?
Looks like the current Google OAuth2 integration requires enabling
Contacts API
Google+ API
from the Google Developers Console for the associated Project. In my log I noticed errors liek 403, Access Not Configured. Please use ....
The redirect URI (where the response is returned to) has to be correct and exactly as you registered in the APIs console, and the error is indicating that you haven't done that or you haven't done it correctly.
To get the redirect URI from console:
Go to the console for your project and look under API Access.
Open Credentials section (in left side)
You should see your client ID & secret there, along with there is a
list of redirect URIs. If you want to change it or it was wrong,
click edit settings and modify.
Even if your redirect uri is properly set in the console, a lot of times, when you've recently changed settings in the google dev console, it will still tell you there's a redirect mismatch. It's a surprisingly common occurrence.
You can try...
Waiting; some have had luck with this, indicating that google takes some amount of time to register recent changes.
If you don't mind reconfiguring your app, creating a new client id in the google dev console tends to fix this problem with consistent results.