I have approved for public_content clientId. To get access token, I send a request to www.instagram.com:
GET /oauth/authorize?client_id=MyClientId&redirect_uri=MyRedirectURL&response_type=code&scope=likes+comments+public_content HTTP/1.1`
After authentication, the browser redirects me to MyRedirectURL and I can get the code from the URL.
With this code I send a request to api.instagram.com:
/oauth/access_token HTTP/1.1
client_id=MyClientId&client_secret=MyClientSecret&grant_type=authorization_code&redirect_uri=MyRedirectURL&code=CodeFromURL`
But sometimes I get response HTTP/1.1 400 Bad Request.
This situation continues for a few hours, and sometimes for a day. It is interesting that the problem is very unstable. I may have two client apps that make identical requests, and one app will work fine, while the other will fail at the same time. Looks like it is a problem somewhere in the Instagram infrastructure.
Instagram is no longer supporting custom schemas for your callback urls. That was my problem, I changed it to https and the problem was solved.
I think you should prefer this document of Instagram.
You may also receive responses with an HTTP response code of 400 (Bad
Request) if we detect spammy behavior by a person using your app.
These errors are unrelated to rate limiting.
It seems like , we can not use http://localhost/... in call back url. Instagram may have restricted it.
It worked for me, when I have added live Ip of my aws server. for example http://xx.xx.xx.xx/.. instead of localhost.
Related
We are developing a chatbot to handle internal and external processes for a local authority. We are trying to display contact information for a particular service from our api endpoint. The HTTP request is successful and delivers, in part, exactly what we want but there's still some unnecessary noise we can't exclude.
We specifically just want the text out of the response ("Response").
Logically, it was thought all we need to do is drill down into ${dialog.api_response.content.Response} but that fails the HTTP request and ${x.content} returns successful but includes Tags, response and the fields within 1.
Is there something simple we've missed using composer to access what we're after or do we need to change the way our endpoint is responding 2? Unfortunately the MS documentation for FrwrkComp is lacking to say the very least.
n.b. The response is currently set up as a (syntactically) SSML response, this is just a test case using an existing resource.
Response in the Emulator
Snippet from FwrkComp
Turns out it was the first thing I tried just syntactically correct. For the case of the code given it was as simple as:
${dialog.api_response.content[0].Response}
I'm confused about this. I have seen a lot of people ending responses with just res.send();. At the same time, some tend to include a status code, like res.status(422).send();. I understand that this is useful when a user, for example, has sent a request to /log-in/ with data that represents a type different from the one needed and appropriate. In such cases, I'm ending my responses with res.status(422).send();. If I'm expecting a username, but I instead receive an array, it seems to me that such an approach is appropriate. However, if everything is technically alright and the user has just entered a username that does not exist, do I need to include a status code? When such a thing happens, a message under the form will be displayed instead. And res.send("This username does not exist."); is the function I would call. Should I call res.status(401).send("This username does not exist."); instead?
Technically you are not forced to use status codes however it's recommended to follow the best practices.
When the user does not exist return 404 not 401. 401 is unauthorized
When user input is not expected, that's validation error(bad request) and return 400 instead of 422. 422 is used in slightly different scenarios.
Read more about it 400 vs 422
More details about http status codes
Yes, status codes are very important as a good practice I would prefer 404 instead of 401 in your case res.status(404).send("This username does not exist.");
stackOverflowAnswer
Why do we use the status code?
To make your debug life easy/ better error handling and to log the error in production to know the severity of the error your application has in case it crashes.
How to Specify statusCode in Node.js
When to use what status code
By default, Express answer all endpoints with 200 unless you didn't specified an endpoint, in this case it will automatically reply with 404.
by the way, Express also has res.sendStatus() function that ends the request and sending status
This has to do with your api design. Generally you would be publishing your api specs (Api specification) and there would mention how your client can find out if something is going wrong or going fine.
HTTP Response code are some of easiest way to inform client about outcome of request. So they don't have to go inside the payload of response to check what was outcome. Since most of codes are well know and there is consensus you will write more standard code which works with network elements like proxies, load-balancer etc and understandable developers.
Advantages of status codes
when trying to post a WakeUp event with a JSON body to the Alexa events API using nodejs with axios or request-promise, the API always returns an error 500.
I posted to an online endpoint to actually see what gets posted and learned that the post body gets truncated which obviously results in invalid json. I abstracted the problem and tried to run it from a virgin nodejs installation by using repl.it and the result is the same.
Interestingly enough, there seems to be a relation between the length of the header and the body. So when I shorten the auth token in the header, more characters of the body get transferred. If I shorten the long tokens in the body to about 450 to 500 characters (it seems to vary) the whole request gets through. Obviously this is not a solution, because the tokens are needed for authentication.
When I experimented with the axios version used lowering it to 0.10 I once got a result but posting again lead to another 500. If I post often enough some requests get trough complete, even on the current axios version. I also tried using request-promise with the same outcome.
I got the feeling that I made a really stupid mistake but I can't find it and I really couldn't find anything on this topic, so it's driving me crazy. Any help would be greatly appreciated!
This looks like a tricky one.. first of all, I don't think you're making a really stupid mistake. It looks to me like one of the low-level modules doesn't like something in the POST body for some reason (really weird.).. I've played about with this and I'm getting exactly the same behaviour with both Axios and Request.. if I comment out the tokens (correlationToken and bearer token ) everything works fine.
If I test this locally, everything works as it should (e.g. set up express server and log POST body).
Also posting to https://postman-echo.com/post works as expected (with the original post data)..
I've created this here: https://repl.it/repls/YoungPuzzlingMonad
It looks to me like the original request to http://posthere.io is failing because of the request size only. If you try a very basic POST with a large JSON body you get the same result.
I get the same result with superagent too.. this leads me to believe this is something server side...
This was not related to the post request at all. The reason for the error after sending the WakeUp event was the missing configuration parameter containing the MACAdresses in the Alexa.WakeOnLANController interface.
I used the AlexaResponse class to add the capability via createPayloadEndpointCapability which had not been modified to support the "new" WakeOnLANController interface yet.
It's a pity that the discovery was accepted and my WOL-capable device was added to my smart home devices although a required parameter was missing :(
posthere.io cutting off long post bodys cost me quite a few hours... On the upside, I go to know many different ways of issuing a post request in node ;)
Thanks again Terry for investigating!
I know that stackoverflow is not the correct place to post this question, but i already post this at serverfault and the place seems generally dead.
--
I noticed weird log entries (unless there's something i don't understand) in my IIS (7.5) logs.
it's an online dictionary with requests ( user friendly url rewriting ) and most of them are GET. However I noticed weird POST requests which are taking place by a person who is trying to crawl our content ( tens of thousands of such requests )
2013-11-09 20:39:27 GET /dict/mylang/word1 - y.y.y.y Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html) - 200 296
2013-11-09 20:39:29 GET /dict/mylang/word2 - z.z.z.z Mozilla/5.0+(iPhone;+CPU+iPhone+OS+6_0+like+Mac+OS+X)+AppleWebKit/536.26+(KHTML,+like+Gecko)+Version/6.0+Mobile/10A5376e+Safari/8536.25+(compatible;+Googlebot-Mobile/2.1;++http://www.google.com/bot.html) - 200 468
2013-11-09 20:39:29 POST /dict/mylang/word3 - x.x.x.x - - 200 2593
The two first requests are legal. Now for the third request, I don't think I have allowed cross domain POST. if that what the third log line means.
all those POST requests take that much time for unknown reasons to me. I would like to know how are those POST requests possible and how can I stop them.
p.s. I have masked the IPs on purpose.
any help would be appreciated! thank you in advance.
blocking POST generally is not an option, i extensively use AJAX. i want to know how does he do this kind of POST request and how to stop him. I've got tens of thousands of requests, i constantly ban IP ranges through firewall but he just hops through proxies.
this is how a normal POST request ( through ajax happens ):
2013-11-10 10:16:54 POST /dict/mylang/displaySem.php - 85.73.156.122 Mozilla/5.0+(Windows+NT+6.1;+rv:25.0)+Gecko/20100101+Firefox/25.0 http://www.mydomain.com/dict/mylang/randomword 200 171
Http allows anyone to POST a request to your site. Your application (not IIS) should check if it is a valid request before starting the long processing algorithm.
Some common validation methods are:
If you think he is directly POSTing to your site using an automated script, you could use a CAPTCHA to make it hard for him: http://en.wikipedia.org/wiki/CAPTCHA
If you think he is hijacking the session of other people, you can use a CSRF field in your form: http://en.wikipedia.org/wiki/Cross-site_request_forgery
I use the Google weather API in my web site, and today I get an error that the API link doesn't return any data.
When I check the link directly I get an (Error 403).
Here is the link.
Can anyone please tell me a solution for this and provide me another link for the API?
Every now and then the API stops working for short periods of time, the last days more often a 403 is trown. For my site, last night it happened 13 times. But the site tries immediately again and the second or third time, the data loads without problems. As the API is unofficial, not sure what’s causing the 403.
Make sure you cache the data as the API will block your IP temporary when you make too much requests. In my case, I cache for 20 minutes and if no data can retrieved, the site will not try more than 10 times to reload the API. Once I forgot to turn caching on after debugging and as my site did many hundred requests (with every visitor), the IP was blocked within an hour. If a remember correct, the error was not a 403. Fortunately, the block lasts for less than a half day.
There is currently an intermittent 403 Forbidden response to the Google Weather API that you are using. See Google Weather API 403 Error
The reason for the intermittent 403 response is not known but has been a problem since the 7th of August 2012.