In what format is it best to return an error in REST - json

What format should I return the response to the API user if an error occurred? Just return the response as a status code and error message:
Full authentication is required to access this resource
(the status 401 was returned)
Or it is better to return it in this format:
{
"timestamp": "2020-06-14T21:20:52.941+0000",
"status": 401,
"error": "Unauthorized",
"message": "Full authentication is required to access this resource",
"path": "/api/users/me"
}

Well, it depends:
If you know your front end urgently requires the direct message of the error, ignoring anything else, then going for the short and direct to the point answer might be your best choice.
But honestly, if experience in programming has taught me anything, is that the more information you have about something, the better, ESPECIALLY IF IT'S an ERROR!!! With the longer response, you have many more tools in you hand, both for giving the final user a better look of your application - You can present for the user a small title, a detailed message and, for example, use an internal code to show a red "error" box if a fatal error ocurred or a "warning" yellow box if a validation simply failed - and especially for the dev to solve that problem (The final user might never see the "timestamp", "status", "path" or stacktrace of the error - He shouldn't... - But it will surely help you track what caused the error).
Take a look at these (1, 2 and 3) articles to help you decide your situation and, if needed, customize your error response structure

Related

Unable to get the output file in Reality Capture API

I am trying to get the proper output from the API but each time it throws an error, and not having enough information about the error makes it more default here is the below example and same happened with other files too
{
"Usage": "0.47476506233215",
"Resource": "/photoscene/XkQN53pc1WCI66ExM6DnjVmKCYb6ZyRZ8ntmwdTjj8U/progress",
"Photoscene":
{
"photosceneid": "XkQN53pc1WCI66ExM6DnjVmKCYb6ZyRZ8ntmwdTjj8U",
"progressmsg": "ERROR",
"progress": "100"
}
}
What are the guidelines for the input images?
Do we have any sample input images for POC?
Thanks in advance!!
From what I've seen, these errors are often caused by insufficient input data. For example, check out this Stack Overflow question: Error: Processing is failing in Autodesk-Forge when converting the image to 3D.
Consider providing more information about your particular case - how many images have you used to reconstruct the scene, what resolution/quality were they?

Penetration test on JSON Api

On my site a penetration test was performed. The following JSON was sent to the site:
{
"name" : "Test',
}
This delivers the following error (with HTTP status code 400):
{
"name": [
"Unterminated string. Expected delimiter: \". Path 'name', line 3, position 1.",
"Unexpected end when deserializing object. Path 'name', line 3, position 1."
]
}
The penetration tester says I should hide this error, because it could give a hint on vulnerabilities of my system.
Is this correct?
The answer for this cannot be very straight forward until we look into your code and whether you have taken care of all security considerations. But on a general note, Improper Error Handling can reveal implementation details that should never be revealed. Such details can provide hackers important clues on potential flaws in the site.
Refer this URL for more details https://www.owasp.org/index.php/Improper_Error_Handling
For example, if I am a hacker then I will try and gather more information about your Deserialization logic and try to break it as you have clearly revealed to me. Deserialization is one of the new OWASP Top 10 Security Issue added 2017. You can please refer the below link for more details
https://www.owasp.org/images/d/d7/Marshaller_Deserialization_Attacks.pdf.pdf

Actionable Messages sometimes are not parsed correctly

We've got reports that sometimes actionable messages are not displayed correctly by some clients. It doesn't matter if they message is displayed on Outlook OWA or Outlook Desktop app.
I asked one of the clients to install Actionable Message debugger app and check the diagnostics section and others. Here are some details I've managed to read off from it:
No card is attached to this message.
Actionable messages processing has not been performed on this message. Actionable messages are only enabled for Office 365.
Adaptive card payload found but could not be parsed. Please validate the payload.
And diagnostics section:
"CardEnabledForMessage": false,
"ClientName": "OutlookWebApp",
"ClientVersion": "16.2528.7.2602797",
"InternetMessageId": "<ID>",
"Error": "EntityDocument does not exist.",
-
"AdaptiveCardPayload": {
"found": true,
"type": "AdaptiveCard"
},
-
"MessageCardPayload": {
"found": false,
"type": null
},
-
"AuthHeader": {
"results": "<address>; dkim=none (message not signed) header.d=none;<address>; dmarc=none action=none header.from=<address>;",
"authAs": "Internal"
}
Up until recently, I wasn't able to reproduce the issue on my end. During some tests, I've sent myself a test message and it has not been parsed correctly.
When I sent another test message afterwards, it was working perfectly fine.
Of course after comparison of both messages' sources yielded that both sources were identical. Headers were a little different but mostly in time and what appears to be the server. Diagnostics and error sections from debugger are almost identical.
The method we use is SMTP (there were some issues with EWS) and we're thinking of switching back if that causes the issue.
Is there something that can be done in regards to this issue? It's probably worth noting that the payload we send is quite 'heavy' (as in, we had to limit ourselves with the amount of data we send because we were hitting something what looked like size limit)
Changing the script slightly makes the messages render for some users. Others had to wait some time (possibly for some OWA update?) for them to work.
So in the end nothing has been changed and it started working after some time.

AccessDenied: Required claim values are not provided when accessing education/users endpoint

I'm unable to access the education/users endpoint but I am able to access other endpoints (education/classes, education/schools).
Whenever I try to get a list of all users, I get the following error:
{
"error": {
"code": "AccessDenied",
"message": "Required claim values are not provided.",
"innerError": {
"request-id": "58c42204-440a-482c-b1e9-4c65bb413ed1",
"date": "2018-03-21T20:23:24"
}
}
}
When I try to make the call using the Graph Explorer, I'm given the following notice:
Failure - Status Code - Looks like you may not have the permissions for this call. Please modify your permissions.
Unfortunately, I get the same error after modifying my permissions.
If anyone has any idea why this might be happening, I would be very grateful for the help.
For app+user (delegate) permissions, the only supported scope for the /education/users collection on MSGraph is EduRoster.ReadBasic.
This supports getting an individual user's information, or information on lists of users within classes of which you are a member, but does NOT support browsing the entire set of users in a tenant, as it is deliberately a restricted scope.
If you need more than this, you would need to use app-only permissions, and sync the users into your own data store with EduRoster.Read.All, which would allow you to get all of the users.

details of success and error responses in rest api

i am writing a rest api in node js and using mssql as my db. I have dilemma regarding the details of success and error responses that the api should return as per rest guidelines. For example if there is an error for key constraints while doing db operations, should the error message be like this
{
"error": {
"code": 500,
"message": "Internal Server Error"
}
}
Or does it needs to be more specific about the error details like the table details. Is it right to give away the internal details through the errors? Does status code needs to be part of the json object? Also, whether the success messages should be more general like "Record created successfully" with 200 code or more specific?
Always think in your final user. If you return the full error message, it will help him? Maybe the user did a wrong request that caused the internal fail. If not, turn it clear and log the error!
For example, when user gets this response, he should repeat the request? Or it's server fault and should wait for fix? So, I suggest something like:
{
"error": {
"code": 1000,
"href": 'http://mywikiapage.com/errors/1000',
"message": "Sorry, we're experiencing some issues. Try again later."
}
}
Note that error code has changed. Its new "custom" code could refer to a wiki page where it gives more details about the error itself. Furthermore, user always can get the 500 result code from HTTP response.
I also would like to suggest the reading of this other SO question