Keep getting the 404 Not Found error on Postman when using the Reddit API what seems to me a perfectly legit request - postman

I am trying to simply return an username i specify in the request to test if an user exists.
To replicate the issue:
URL:
https://oauth.reddit.com/api/v1/user/*usernamehere*/about
Type of request: POST
Headers:
User-Agent: My app
Authorization: Bearer MyTokenHere
Content-Type: application/x-www-form-urlencoded
I'm not sure what I'm doing wrong. I am 100% positive the token I am using is valid.
If I change the request to GET I get the Bad Request error.
Anyone can help?
I was expecting some successful payload about an user and not an error

Related

Django Dev Server Processing The Same Ajax Request Inconsistently

I'm submitting a POST using ajax clientside. It works fine whenever all the requests are valid. However, when I send a POST request to an invalid URL, and then follow it up with another POST request, regardless of whether it's valid, Django processes the request in a completely different manner. Before changing some code it was actually causing the server to crash.
Heres what happens in the Django server stdout when I send two invalid requests in a row:
Not Found: /profile/add_favorite
[01/Aug/2019 15:42:25] "POST /profile/add_favorite HTTP/1.1" 404 4132
Not Found: /profile/add_favorite
[01/Aug/2019 15:42:30] "title=Video+TitlePOST /profile/add_favorite HTTP/1.1" 404 4178
The second request looks ill-formatted, and it's of a different format than the previous request.
The request was sent using basic Ajax:
var conf = {
type: 'POST',
url: url,
data: {title: "Video Title"},
headers: {'X-CSRFToken': csrftoken},
}
$.ajax(conf)
And in the dev tools I checked that the requests were the same:
That's just the headers but the data is also the same. Anyways, the exact same code was used for both request. This only happens when I send a request to an invalid URL and then send another request after it, and if I reload the page after sending an invalid request and send another request that request will work like it should, but not without returning a messed up response first.
Behold: If I send a post request to an invalid URL and then reload the page in Chrome chrome will not send a valid GET request, instead it sends a request with the same prepended title, the same invalid format!
[01/Aug/2019 16:04:03] "title=Video TitleGET / HTTP/1.1" 403 2513
Then that's the issue:
Whenever I send an invalid url Ajax request from my browser, the next request to my server will be made invalid in the same way. I feel sure it's not a browser-side issue, because I can send an incorrect request from one window, and then the next request from a different window will be incorrect! This is the screen from that next request:
The CSRF token shouldn't even matter the first time a site is loaded, making this message nonsensical.
This is obviously an problem of incredible magnitude for my server, as any time a person sends a request to an invalid URL at my server then the next request will not process correctly.
This must be a bug with the Django development server? What could possibly cause this?

View postman request when redirects

I am using Postman to submit request. Server responds with
HTTP/1.0 302 Found
Location: https://services.****.com/*/***/ed36317f-8d77-4d62-9926-f9700bee9b6c
Server: ****
Connection: Keep-Alive
Content-Length: 0
Postman follows this redirect. I wish to see this new request in Postman console. Can someone tell me how I can view how Postman formed new request?
In Settings, turn off "Automatically follow redirects".
Automatically follow redirects: Prevent requests that return a
300-series response from being automatically redirected.
from https://www.getpostman.com/docs/v6/postman/launching_postman/settings

Amazon Cloud Drive 404 <UnknownOperationException/>

I am trying to get an access_token using the code I get once the permission is granted by the resource owner. My request is like:
URI:
https://api.amazon.com/auth/o2/token
BODY:
client_id=amzn1.application-oa2-client.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&client_secret=%090xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&code=xxxxxxxxxxxxxxxxxxxxxxxxxx&grant_type=authorization_code&redirect_uri=https%3A%2F%2Flocalhost&scope=clouddrive%3Awrite
HEADERS:
host api.amazon.com:443
user-agent MySockets
content-type application/x-www-form-urlencoded
content-length 271
connection close
I get the error:
404
Please can anyone point me to what I am doing wrong here.
Problem was that my socket library was sending "GET" http method. Once I set it to "POST" it worked!

What is the proper HTTP status code for indicating authorization obligations?

I have a HTTP "rest" web service API that I am creating for accessing user data.
The web service integrates with a XACML policy decision point. The policy decision point determines if the request is authorized as a function of the user and the data being accessed. Generally, the response is "permit" (action is allowed) or "deny" (action is not allowed).
If permit, then the call continues and data is returned.
If deny, then the call is aborted and an HTTP 403 (forbidden) is returned.
However, certain policies have "obligations" to indicate that the action is conditionally allowed with further action. The analogy that I generally use is the "this credit card transaction may be allowed, but the clerk needs to view the customer's ID, and then make this call again asserting that the ID matches the credit card".
In my web service, I want to prompt the client to take action and include additional information in the request URL to indicate that the obligation was met. I am communicating this information with structured body response understood by the client application.
My question is what is the appropriate HTTP status code to use in the scenario.
"403" would not be appropriate (text from HTTP spec Authorization will not help and the request SHOULD NOT be repeated).
My best guess would "401" (unauthorized), but I am not sure if this status code is specifically around the use of the authorization header and username/password type of concerns.
Maybe you could use the HTTP status code 303 or 307 to point the user to a temporary redirect location that somehow encodes the extra "obligation"?
A 401 response seems reasonable to me. The HTTP authentication mechanism is extensible, so you could conceivably create a custom authentication scheme so that you are properly setting the WWW-Authenticate header as required by the RFC. Browsers won't know what to do with your custom scheme, but I assume your clients aren't browsers anyway, if they have to understand what an obligation is.
Example request sequence:
PUT /some/resource/that/has/obligations HTTP/1.1
Content-Type: application/json
Authorization: token my-oauth-token
HTTP/1.1 401 Unauthorized
WWW-Authenticate: obligation urn:my-app:my-obligation;param1;param2
PUT /some/resource/that/has/obligations HTTP/1.1
Content-Type: application/json
Authorization: token my-oauth-token
Authorization: obligation urn:my-app:my-obligation:result=ok
HTTP/1.1 201 Created
Location: /some/resource/that/has/obligations/1
Another option would be to return a 202 on the initial post or put, and then confirm it on a later post. This option would require a little more state management server side, since you'd first accept the operation, and then wait for the client to confirm it.
PUT /some/resource/that/has/obligations HTTP/1.1
Content-Type: application/json
Authorization: token my-oauth-token
HTTP/1.1 202 Accepted
Location: /some/resource/that/has/obligations/1
X-Obligation: urn:my-app:my-obligation;param1;param2
POST /some/resource/that/has/obligations/1 HTTP/1.1
Content-Type: application/json
Authorization: token my-oauth-token
X-Obligation: urn:my-app:my-obligation;result=ok
HTTP/1.1 200 OK
One thing to always keep in mind with obligations, though... they're always enforced client-side, so unless the obligation involves hitting another service that your service can double-check against, you never know if the client actually performed the obligation. If you don't control the client, then obligations are really just theatre.

Able to GET authenticate but not POST authenticate

I am trying to connect to a REST API, using C#.
I was able to successfully do some GET request but POST kept giving me 401 Authentication error.
I have gone ahead and downloaded fiddler and this is what my requests look like:
GET (Works)
Request Headers
GET https: //hello.myurl.com/api HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: application/xml
Authorization: Basic ***************************************************************************************************
Host: hello.myurl.com
-
POST (Doesn't work)
Request Headers
POST https: //hello.myurl.com/api HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: application/xml
Authorization: Basic ***************************************************************************************************
Host: hello.myurl.com
Content-Length: 12
Request Body
status=hello
(* same in both using
String authinfo = "username:password";
Convert.ToBase64String(Encoding.ASCII.GetBytes(authInfo));
Any ideas why?
I'd consult the API documentation for that particular URL. GET requests are simply requesting a readonly version of data, a POST request is implying that you are making a change to a certain URL, so it's possible that the API allows GET requests without authentication, but requires authentication on the POST request.
In your case I'd hazard a guess that your authentication is not correct, but it's just being ignored on the GET request as it doesnt need authentication.