You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Brief Description
In pub-get-stats-all/index.js, when an exception is thrown, the app returns a server 500 and attempts to convert the exception to a JSON object to send back to the client.
But this conversion process is broken, meaning that the client never receives any details about the error, just a 500 status with no further information.
The problem is that calling JSON.stringify(err) on an exception object err returns {}. The call needs to be JSON.stringify(err, Object.getOwnPropertyNames(err)).
The text was updated successfully, but these errors were encountered:
@simon-20, for a 500 error, would it be better to log the exception details, rather than return them to the user, as it exposes information about the internal workings of the app?
@simon-20, for a 500 error, would it be better to log the exception details, rather than return them to the user, as it exposes information about the internal workings of the app?
Hi Tilly, that's probably a good idea, even just for security reasons. It's likely to be IATI Devs who are using this info, though, so perhaps not something completely generic?
Brief Description
In
pub-get-stats-all/index.js
, when an exception is thrown, the app returns a server 500 and attempts to convert the exception to a JSON object to send back to the client.But this conversion process is broken, meaning that the client never receives any details about the error, just a 500 status with no further information.
The problem is that calling
JSON.stringify(err)
on an exception objecterr
returns{}
. The call needs to beJSON.stringify(err, Object.getOwnPropertyNames(err))
.The text was updated successfully, but these errors were encountered: