Trying to make a post request to
POST /sites/{siteId}/drive/items/{itemId}/createUploadSession
according to
https://learn.microsoft.com/en-us/onedrive/developer/rest-api/api/driveitem_createuploadsession?view=odsp-graph-online
I expected a 200 response with an upload url, but got a 403, despite having all relevant permissions.
The endpoint seems to require a PUT request instead of POST despite all other answered posts and the documentation indicating otherwise
Related
In postman I want to create a GET request that returns a 302 status code (along with a Location response header). I have been trying to replicate the original request from the browser inspector, but I always get a 200 response (and no Location response header).
How can I get the desired response with the Location response header?
Please try to turn off automatical redirects (File->Settings: General Tab):
What is probably happening is that Postman receives a 302 status code, but is configured to redirect in this case, so it automatically redirects after which Postman receives a 200 status code, which is what you end up seeing.
Apparently turning off "automatically follow redirects" should offer you a solution.
https://learning.getpostman.com/docs/postman/launching_postman/settings/
View postman request when redirects
I'm using PostMan to troubleshoot an odd 400 error with my Angular / NodeJS app.
I'm trying to GET https://example.com/login.html and the request has two headers:
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGc...== and Accept: text/html
This returns a 400 Bad Request error (server: cloudflare-nginx)
This works fine (returns 200) if:
I access the file in my local environment on http://localhost:5000/login.html (no https factor?) -or-
I remove Authorization: Bearer from the header
If I watch my NodeJS server logs, I don't even see the request come through. So /login.html doesn't even get hit, I assume because Express is rejecting it before my app.use(logger('dev')); picks it up.
UPDATE: I believe Cloudflare is kicking it back with 400 prior to the request ever reaching Heroku.
A few more points:
I am using JWT to authenticate users, which is where the Bearer token comes from.
If I access other endpoints, such as /profile with the Bearer token, it responds properly with the user profile from decoding the token.
My question is:
Why would this request be a "Bad Request" when it works on other endpoints?
Is there a way to catch this and do something with the request before it's returned as 400?
As it turns out, the issue was related to my implementation of JWT. For some reason, one user continued to receive a token that caused these 400 errors, even though the token was verified as valid using JWT.io.
I made two significant changes that fixed the issue:
I was embedding the full user profile (long JSON) in the token payload. I reduced it to just their userid, both for performance reasons (far smaller size) and just in case something in the complex payload was causing the issue.
I switched from JWT-Simple to jsonwebtoken in my node implementation.
I'm just glad that worked. My next step was to switch from 'Authorization' to 'x-encoded-auth' or some other custom name.
#James, I don't have enough reputation to post a comment on your answer, but I thought it would be helpful to others struggling with this issue to state that your suggestion to reduce the complexity/size of the signed user indeed resulted in resolving similar issues I was experiencing. This was on my list of performance optimizations anyway - but it didn't occur to me that it could be a cause for error in this scenario - so you deserve the credit... thanks!
For readers - there are some useful links in this SO thread about max size for tokens: What is the maximum size of JWT token?
And this is a tool I use to check the validity of a generated tokens... https://www.base64decode.org/
Hope this justifies the upgrade from comment to answer!
this is a similar question to this post in SO.But the answer provided here cannot be applied in my case as i cannot change the response headers from server.
Suppose an http POST to a different origin. This implies CORS, including a CORS preflight exchange. Now suppose the OPTIONS request returns a 503 service unavailable error due to a server problem. In this case the error handler gives ""for data and 0 for status instead of giving me the status code 503 and the text:service not available. An example of this scenario is illustrated in the below image.
I am using angularjs $http and i know in the response there are no CORS header if such errors happen.and i cannot change it.
Is there any way i can receive the proper error code and the text in my rejection object.
This is not an issue of AngularJS / $http but it is the behavior of the browsers and their XMLHttpRequest object: If the CORS request fails, the browser does not give any information back to the caller.
Before I got this understanding, I also though it to be an AngularJS issue and I raised an open issue on github of Angular -> with the corresponding comment.
https://github.com/angular/angular.js/issues/13085#issuecomment-148047721
So I think there seems no other way to solve this as to add the Access-Control-Allow-Origin response header also on the proxy / load balancer in case of 503.
Edit:
If your load balancer is a HAproxy, the following may help you too:
HAproxy: different 503 errorfile for OPTIONS and POST methods
It shows how to let HAproxy anwer the CORS requests autonomous.
I have the following AJAX function that I call to send post request to a web server running in Python, using Cherrypy, which runs behind Apache:
oAjax.open("POST", "/", true);
oAjax.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
oAjax.setRequestHeader("Content-length", parameters.length);
oAjax.send(parameters);
The parameters are being sent as follows:
"id=pagename&action=pageaction"
Every now and then, I get empty post data when a request is sent. This does not seem to be consistent.
Using WireShark, we get the following details for a bad request:
HTTP 543 POST /? HTTP/1.1 , NTLMSSP_NEGOTIATE
In these cases, we seem to have 0 content length, so our post data seems to have been removed.
It appears to be trying to re-authorize the session when not required, causing the post data to be lost.
Does anyone know why this would happen?
This does not occur in FireFox.
Using the information found on this website, I was able to solve the problem:
http://support.microsoft.com/kb/251404
My web application uses ajax and i check request is ajax request or not via php codes. If not then i generate 404 error otherwise run php codes that associated ajax function.
If user or search spider tries to reach ajax function page(ex: /books/ajax/books_list) web app return 404 not found status code and i see a lot of 404 errors in google webmaster tools.
I should change 404 status code but which one is right for this condition ? Can be "406 not acceptable" ?
I think 403 (Forbidden) probably best describes it. The resource is there, but you've determined that you're not going to give access to that resource, and even authenticating the user isn't going to help.
I would suggest that you return the 406 you suggested. The only alternatives worth considering are '501 not implemented'
The server does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize the request
method and is not capable of supporting it for any resource
And '403 Forbidden'
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe
the reason for the refusal in the entity. If the server does not
wish to make this information available to the client, the status
code 404 (Not Found) can be used instead.
Not sure how you determine whether it's a proper Ajax request. If you expect it to be POST, but the spider uses GET, then it should be 405 (Method Not Allowed).
You should not be using 406: it means "not acceptable", in the sense that you cannot support the HTTP Accept: headers that the browser sent. This would likely be incorrect (as you likely aren't checking the Accept headers at all).
If you really reject the request because it comes from an unauthorized client, then 403 is appropriate.
It's my understanding that SE spiders get a little skittish if they see errors that indicate server problems. (A 406 can indicate a badly implemented server.) A 404 doesn't describe what you're looking for, as the resource is there, but a 403 (forbidden) just lets the spider know that this page isn't for them. You can also use your robots.txt file.