I have been getting this error message the past 36 hours. Facebook support has not been any help at all when it comes to resolving this issue. I've cleared my cookies and cache multiple times. I've tried from multiple machines as well as my phone. Still no luck on logging in. Is it an error on my part or are they doing maintenance? Please assist, I did not want to have to post here but I have no more options...
The website cannot display the page
HTTP 500
Most likely causes:
•The website is under maintenance.
•The website has a programming error.
What you can try:
Refresh the page.
Go back to the previous page.
More information
This error (HTTP 500 Internal Server Error) means that the website you are visiting had a server problem which prevented the webpage from displaying.
For more information about HTTP errors, see Help.
It's probably something on their end. Responses with a 5xx status code are used when the server is aware it has erred in some way. More specifically, the 500 error has the following definition:
500 Internal Server Error:
The server encountered an unexpected condition which prevented it from
fulfilling the request.
If the response had a 4xx status code, then the fault would lie on you. For example, if you made a request to a resource that doesn't exist, then you'd get a 404 response. As it stands now, something is wrong with their server.
Had the same problem. It appeared to be caused by this:
https://developers.facebook.com/docs/facebook-login/login-flow-for-web/v2.1#asking-for-permissions
Apps that ask for more than public_profile, email and user_friends must be reviewed by Facebook before they can be made available to the general public.
We were asking for more than the default, so I presume the 500 is caused by this lack of review.
It appears it can also happen if you haven't made your App public and try to login to it as anyone but you (the account that created the App).
Related
I'm working on a music media library that allows users to share music in their library but only if they marked as shareable.
In the backend I'm checking if the music file is shareable like so
if(file.shareable) share
else throw 500 or 400?
To me this is a 400 bad request because the the user is trying to do something that the business does not allow.
Is this the corret way?
4xx indicates a bad request -- i.e. "don't try re-requesting".
5xx indicates that the server had a problem, i.e. "give us a minute, and try again later."
So if it's business logic, that would be a 400 level error, i.e. don't re-request.
You should use 4xx codes for any client error that prevents the server from returning a useful response. This includes requests that violates business rules. The point is to indicate to the client that the request is invalid, and potentially include steps the client can take to fix the situation.
Use 5xx codes if the server encounters an internal problem that prevents it from doing its work. Maybe the database or a necessary external service is down, or there's a programming error somewhere. Maybe the server is just too busy right now. Not much the client can do to fix that other than try again later.
Basically:
4xx: Your fault.
5xx: My fault.
I'm going step-by-step Nest REST Quick Guide and now blocked with error response during attempts to obtain an access token.
Response is:
{"error":"client_not_active","error_description":"client is not active","instance_id":"here_is_something_looks_like_guid"}
I've checked Error Messages Guide, and it helps me a lot to understand that "Client not active". Useful, huh?
So which client and how to activate it?
I have a home simulator working, also I've registered a so-called 'product', which I want to develop (so I have Product ID, Product Secret, Authorization URL and Access Token URL).
[Upd]
For all operations I've used curl.
However with Firefox addon which sends POST data I'm able to obtain the access_token. So I keep the question, but so far will stick to browser.
This means the your product/client has been deactivated, most likely due to a violation of the Terms of Service. Is the problem consistently occurring?
What status code should be returned if somebody request access to the entity that he is not permitted to see? You'll probably say it's 403: Forbidden. But is it common practice to return 404 instead? I don't want somebody know that this entity even exists if he is not permitted to see it. What do you think?
Use 404 Not found.
The 404 status code can also be used in 403 scenarios, when the server
does not want to send back the reason why it is refusing to serve the
request. A good example is when the server senses some kind of an
attack, which might be a brute force attack. In this case, the
server responds with a 404 Not found instead of a 403 Forbidden and an
explanation.
Source: Pro ASP.NET Web API Security
Return 403 Forbidden. If you return this for every request the client is not allowed to access and if you never return 404 Not Found, the client knows nothing.
It all depends on how important this is for you:
I don't want somebody know that this entity even exists if he is not permitted to see it.
If this really is important, always return 403 Forbidden.
Well.. it depends..
If your endpoints' URLs reveal sensitive information (e.g., in Dropbox API, you refer to files by their names, rather than their IDs - so the URLs contain the file names) or perhaps you're using sequential IDs (e.g., ascending IDs that can be brute-forced), return 404.
If you need to support a "Request Access" feature to resources you don't have permissions for, return 403, so your client-side could tell the difference.
Generally speaking, if your API uses IDs and never reveal information as part of its URLs and you're using UUIDs as IDs, I would go with 403.. as with many well-known and very secured applications nowadays (Google, Microsoft, etc..).
Hope you get some clarification on HTTP errors based on what I am posting below:
HTTP 401 error :: This error happens when a website visitor tries to access a restricted web page but isn't authorized to do so.
HTTP 403 error :: This error is similar to the 401 error, but note the difference between unauthorized and forbidden. This can for example happen if you try to access a directory(forbidden) on any website.
HTTP 404 error :: A 404 error happens when you try to access a resource on a web server (usually a web page) that doesn't exist.
I have a RESTful service that throws a 500 INTERNAL SERVER ERROR status upon an internal failure for a number of reasons: DB errors upon connectivity or field size, code bugs, or issues with a managed code call. The resulting unhandled exception is reported back by IIS as a 500. Is this an appropriate use of 500? It could imply "retry request" according to MSDN Common REST API Error Codes. The proper API error code I am seeking is something like "### Server will NEVER process this request until a code change is made, do not resend or you will be looping forever and DOSing my server". Would a 400 Bad Request be more appropriate? It seems as if this is indicating a malformed request syntax itself, not that the service choked.
Furthermore, what should a client do when it encounters such an error? The server does not want another RESTful operation exactly like the previous one. The user may have spent some time doing data entry. Now we have to talk them off the ledge. Perhaps they can fix it on their own and that is the best practice? What are some similar experiences developers have had and how was it solved? Thanks.
4xx errors are "something is wrong with the client, they're sending the wrong stuff".
5xx errors are "something is wrong with the server, sorry it's out sick today."
Which basically means there's nothing the client can imply from a 5xx error. It could be permanent, it could be transient, the client doesn't know.
IIS sends a 500 error because IT doesn't know what happened. If your app is blindly throwing exceptions up to the web tier, there's not much more it can do or say about it.
If the server logic somehow actually KNOWS what's wrong, and WHEN it might be fixed, it can send a 503 error, telling the client it's unavailable and a Retry-After header telling the client when it will be back.
As for a client behavior, it's sort of dependent on the clients history with the service. Maybe the service intermittently fails with 500 errors, and another request will just work. This could happen, say, if you have a set of load balanced servers. The first server they hit is sick, but perhaps not sick enough that the load balancer has taken it out of rotation yet. So, another server may be just fine -- in that case the client could just retry and see what happens.
But in the end, it's up to the client as to what to do. It could try a simple back off algorithm. Retry once or twice. Retry once immediately, then again in 10s.
Or it could just push the 500 error back to the user with a polite message "tough luck".
Only the client use cases and requirements can really dictate what it's behavior should be when the server is dead.
At the client side, we have to assume that the web-service is good, and that this either a malformed request (i.e. the user has keyed in something in-appropriate), or a network error of some kind. The method I used is to use an alert box, requesting the user to refresh the screen (F5), and try again with proper input. You may want to add "in case error persists, contact ...".
getting the error {"error":{"message":"(#100) Can only call this method on valid test users for your app","type":"OAuthException"}} whenever trying to write to any facebook end point. Reading (GET) works fine, writing (POST) fails. Does anybody know how to resolve this?
I have also opened a ticket on FB dev site:
http://developers.facebook.com/bugs/184198634991192?browse=search_4e93328871c8a3231774584
The problem does not occur is I would shoot the POST request from my browser as if I am the user.
The problem does occurs only when sending from our servers on behalf of the user from one of our dev machines which have other subdomain names instead of www (such as dev1.blablabla.com & dev2.blablabla.com, while the app is registered to www.blablabla.com).
So the question is, does facebook attempt to do a reverse DNS lookup on all write requests to verify the source?
I believe your requirement is to get the user details of the owner of Facebook access token (normally the currently logged in user)
For that you have to issue a GET request and not a POST request.
The reason why it works when fired from the browser is that when you submit a query through the address bar it is send as a GET request, and when sent from your server it is send as POST and fails producing the error message mentioned in your post.
Facebook doesn't do a reverse DNS lookup on your write request and not need to configure anything in your server related to it.
Hope the answer is clear enough for you.