search

EIDA / userfeedback

This repository is meant to collect feedback from EIDA users by means of its Issue Tracker
11 stars 5 forks source link

FDSNWS error messages not consistent among nodes #2

Closed flofux closed 5 years ago

flofux commented 5 years ago

Hi, while testing the token system, I realized that the different EIDA nodes do not provide the same error messages for FDSNWS requests to restricted data without a token.

ODC, LMU and INGV node correctly return a "Access denied" message, when not using a token for Z3 data.

ETH and RESIF node simply return a "No data available" message, when not using a token for Z3 data, which is somewhat misleading.

I did not test any other nodes. It's not a big deal, but correct messages will help the users identify the reason why they cannot download any data.

javiquinte commented 5 years ago

@sheimers Could you post your SC3 version and details about the python file where this error comes from? (size, date, line where this error can be found) @jschaeff Can you check if the code you run is capable of returning "Access denied" in case no token (or an invalid one) is presented?

Jollyfant commented 5 years ago

This was changed in SeisComP3 by @andres-h here https://github.com/SeisComP3/seiscomp3/commit/e4187beb8b4454a532cfe99fad1113dc54b1a3f2. It should be fixed with the newest version of SC3.

flofux commented 5 years ago

I also noted that when I request waveform data that is not available the ObsPy RoutingClient sometimes returns an empty stream and sometimes returns an error message, e.g.: No data available for request.

Ideally this should also be consistent ... I spotted it today on the ODC node, but haven't checked other nodes systematically.

Edit: observing for which stations this happens, I speculate that the No data available response is returned if station metadata is not existing for the requested time (either because it's missing completely, or because the station has been closed), or if the station is not properly routed (as A020B currently). In contrast, the empty stream is returned for stations with metadata when simply no data is existing at EIDA.

Jollyfant commented 5 years ago

Do you think that is an effect of the way ObsPy implements the APIs?

sheimers commented 5 years ago

Currently we run Seiscomp3 217.124 on eida.ethz.ch. We plan to upgrade to 2018.327 within a few days. We postponed the update because we had some software depending on the old database scheme, but this is now solved.

The "no data available" seems to come from lib/python/seiscomp/sds.py, line 298. 

sysop@eida:/usr/local/lib/python/seiscomp$ ls -la sds.py
-rw-rw-r-- 1 sysop sysop 12741 Oct 12  2016 sds.py

But in the new version 2018.327 it is still "no data available". 

sysop@sc3d:/usr/local/lib/python/seiscomp$ ls -la  sds.py
-rw-rw-r-- 1 sysop sysop 12654 Mar 29 11:04 sds.py
sheimers commented 5 years ago

Today we have upgraded eida.ethz.ch to Ubuntu 18.04 and Seiscomp3 2018.327.p10. We have also upgraded the eidaws routing service to the latest git release.

javiquinte commented 5 years ago

I tested it and it seems solved at ETH. Thanks @sheimers ! Let's wait for RESIF.

HTTP error 403, reason Forbidden, while downloading 'http://www.orfeus-eu.org/fdsnws/dataselect/1/query': b'Error 403: Forbidden\n\naccess denied HTTP error 403, reason Forbidden, while downloading 'http://erde.geophysik.uni-muenchen.de/fdsnws/dataselect/1/query': b'Error 403: Forbidden\n\naccess denied HTTP error 403, reason Forbidden, while downloading 'http://eida.ethz.ch/fdsnws/dataselect/1/query': b'Error 403: Forbidden\n\naccess denied HTTP error 403, reason Forbidden, while downloading 'http://webservices.ingv.it/fdsnws/dataselect/1/query': b'Error 403: Forbidden\n\naccess denied Downloaded http://ws.resif.fr/fdsnws/dataselect/1/query with HTTP code: 204

jschaeff commented 5 years ago

From RESIF's perspective, the error message is logical: The user requested some data, but we can not serve them, either because we don't host it or because the user is not authorized to get them. I acknowledge that it would help the user to know which of those 2 reasons led to the error, but it's not easy to implement on our side. Furthermore, I guess our implementation is FDSN compliant even with this problem (am I right here?) If it's OK with you, I'll treat this issue with lower priority, and come back to you with some solution.

javiquinte commented 5 years ago

From RESIF's perspective, the error message is logical: The user requested some data, but we can not serve them, either because we don't host it or because the user is not authorized to get them. I acknowledge that it would help the user to know which of those 2 reasons led to the error, but it's not easy to implement on our side. Furthermore, I guess our implementation is FDSN compliant even with this problem (am I right here?) If it's OK with you, I'll treat this issue with lower priority, and come back to you with some solution.

I agree, Jonathan. Keep it with very low priority. I will change this to "wontfix" and close it for the time being, but if you find some time in the future it would be nice to have it.