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
The current implementation of federated query error visualization does not allow the user to see neither the query executed to the other endpoint nor the returned error. Only a short error message of the local query engine is shown. This makes it really hard to debug and fix the query.
In the best case scenario (if the user has some knowledge of the inner workings of the query engine and it's possible to deduce the query indirectly sent to the other endpoint) it is possible to execute manually the request and debug the error, like done here or here.
However it's not good to require the user to have knowledge of the inner workings of the query engine in order to write correct queries.
Also, it's not always possible to deduce [in a reasonable time] the query executed on the other endpoint.
I believe that the interface should show the query executed to the other endpoint and/or the error returned by it.
Regarding the query executed to the other endpoint, I'm not entirely sure if it is safe to show it, it would probably be a good idea to do a security risk evaluation to check if it could be used by malicious third parties as feedback while trying to find SSRF vulnerabilities.
Regarding the error returned by the other endpoint, I don't see any security concern (maybe it's a good idea to remove the sent query, if it is echoed inside the error response).
As for how to display it, I believe a button to open a popup with these details could be placed inside the error section and/or in the box for the SERVICE inside the Analysis popup:
The text was updated successfully, but these errors were encountered:
The current implementation of federated query error visualization does not allow the user to see neither the query executed to the other endpoint nor the returned error. Only a short error message of the local query engine is shown. This makes it really hard to debug and fix the query.
In the best case scenario (if the user has some knowledge of the inner workings of the query engine and it's possible to deduce the query indirectly sent to the other endpoint) it is possible to execute manually the request and debug the error, like done here or here.
However it's not good to require the user to have knowledge of the inner workings of the query engine in order to write correct queries.
Also, it's not always possible to deduce [in a reasonable time] the query executed on the other endpoint.
I believe that the interface should show the query executed to the other endpoint and/or the error returned by it.
Regarding the query executed to the other endpoint, I'm not entirely sure if it is safe to show it, it would probably be a good idea to do a security risk evaluation to check if it could be used by malicious third parties as feedback while trying to find SSRF vulnerabilities.
Regarding the error returned by the other endpoint, I don't see any security concern (maybe it's a good idea to remove the sent query, if it is echoed inside the error response).
As for how to display it, I believe a button to open a popup with these details could be placed inside the error section and/or in the box for the SERVICE inside the Analysis popup:
The text was updated successfully, but these errors were encountered: