My server returns a 403 forbidden error when a user tries to access a resource that they do not have access to. Along with the header the server also writes a small message describing the error.
In Firefox the error message gets displayed nicely and the user knows what's going on.
In Internet Explorer the message is hidden and replaced with the 403 Forbidden standard error page.
Are there any specific rules that allow me to display an error message across all browsers while still setting the status to 403 Forbidden?
Here is the RFC info on this status:
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.
It seems like I should be setting a message but IE just won't display it.
Try making your 403 page larger (i.e. more bytes). Some browsers assume that a short error page is the default page from the web server and decide to show their own, presumably more helpful text.
More info.
The implementation of error handling is browser dependent. In HTTP if you are just going to return a 403 error then you have to rely on the user agent (the technical name for the browser, the recipient of your error message may not be a browser) to handle out how it sees fit.
If you don't like how the browsers are handling 403 errors and want to ensure a consistent user experience across all browsers then redirect the user to your own 'permission denied' page. You can build a page that can explain to them why permission was denied and what they might be able to do about it. And it will be consistent for any browser.
Related
Starting from two Sharepoint domains, say accessible.sharepoint.com and unaccesible.sharepoint.com, from POSTMAN, we are able to access _api/contextinfo in the first case (200 OK), but not in the second (403 Forbidden).
In concrete:
{"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Attempted to perform an unauthorized operation."}}}
Could someone tell me what actions I have to ask the technicians who control the unaccesible.sharepoint.com domain to carry out?
Finally, we are able to do that, connecting to site level:
https://unaccesible.sharepoint.com/sites/<our_site>/_api/contextinfo
I am building an API on NodeJS and I would like to use the correct HTTP returns for the created interfaces. I am using the placements indicated on the sites:
My question:
I built the "checkEmail" API with ajax. The page calls the server, which checks whether the email entered by the user exists or not. Theoretically, when a resource is not found, I should return a 404. If the email does not exist, I return a 404 - which in this case is a success for the user (he can use this email). However, if an email exists, I return a 200. This, for purposes of the screen, returns an error because the email is already in use and the user will have to enter another one. The last case would be if the user entered an invalid email. In this case I return a 500, stating that the content you entered is not a valid email.
Is this logic correct? I am in doubt as I am using 404 for success (in this case) and 200 for failure (email found - already used).
Thanks.
500 should used for server errors only (Like an internal exception) where as 400 errors imply client error such as invalid input. For invalid email, that would be a 400 family since the client could change the input email and it may succeed.
For an object that doesn't exist in a database, there is a debate on whether it should be a 20x or a 404. I personally don't like 404 just for missing objects in a database for an API since it could also look like the route doesn't exist. (i.e. I types in /user/1234 instead of userS/1234 when the routes was defined as /users/{id}. Most frameworks now have a 404 catch all if the route template doesn't exist which may need my attention. Same goes for reverse proxies in the middle that could be routing to different API servers. I like knowing from a quick glance if the route template is correct and that the object is just doesn't exist in a Db.
So this brings up which 200. You could use 204 (No Content), which means the body doesn't have any content (But that doesn't imply the database doesn't). Many use this for a DELETE which doesn't return the deleted object back. 204 has more meaning in browsers rather than a pure AJAX API, but it definitly works. You could also use just a plan 200.
500 is used for server error and 40- for user errors i suggest 200 for bot cases found and not but changing body result
This endpoint on Spotify's Web Api throws a 500 error for the username "spotify":
GET https://api.spotify.com/v1/users/{user_id}/playlists
Is this intentional on Spotify's end? Does Spotify not wants developers to access its playlists.
Note - All other usernames work fine
A 500 error should always be treated as being unintentional. If the server side wants to limit access a response code in the 400 range should be used instead, like 403 or possibly 401. It is likely that there are so many different public playlists for the Spotify account that one of them has triggered a bug. If for some reason the error code 500 is intentional, it is still a bug, but in the API, which should be fixed.
I work at Spotify, but don't have direct access to this system. I will let people know.
We have been getting an error prompt/alert in our XPages application at random times:
"An error occurred while updating some of the page...status:12152" and
"An error occurred while updating some of the page...status:12029"
We can't seem to pin it down to anything. Maybe someone has an idea of what these errors are referring to or maybe how to track it back to something? Thanks.
The HTTP 12152 error usually points to a network connection issue rather than anything specific to the browser or the Domino server.12029 again is down to an inability to make a connection to the server.
It sounds like the network connection is intermittent. I don't know what tools there are to test that, but I would suggest confirming you have a good, stable network connection between PC and server and that it's not getting negatively impacted by a firewall.
It looks like your application is trying to partially refresh content on the screen, and that this partial refresh fails. This can be because the component with that id is no longer found in the component tree.
Have a look at your XPages source code for controls with an id of MainContent and refreshPanel3 and find any partial refreshes on those controls. Check the rendered/loaded property for these controls to see if they are hidden in certain cases. If you do not render a control and want to display it using a partial refresh, you must partially refresh an outer component that contains the non-rendered control.
Use browser's network debug (F12 in Chrome/IE/Firefox w Firebug) to get real server response, it usually contains error page with more info. Failed partial refresh should be the last POST request.
I you fiddler core to monitor web traffic from the browser. However I have a problem when website does not exist. Fiddler then displays custom error message that website do not exist. I would like to display the standard error message from the browser... Maybe somebody knows how to do that?
Regards,
Andrzej
The short answer is that "You can't pretend like a proxy isn't there" when it really is. Having said that, the reason you see the Fiddler error message is because I deliberately pad the response body out to 512 bytes so that the error message is shown instead of IE's Friendly error message. If you'd instead like to show a different error message (including one shorter than 256 bytes to ensure that the client gets the browser's "Friendly" error page if that option is configured, you can do so by intercepting the FiddlerApplication.BeforeReturningError event and replacing the response body with whatever you'd like.