[trunk] fix dataselect restricted handling

[gempa-stephan]

The SC3 datamodel includes a restricted attribute at network, station and channel level.

A FDSNWS station query with restricted=false will exclude all streams with a restricted flag set to true either on the network, station or channel level.

In contrast, the FDSWS dataselect service currently evaluates the restricted flag only on the channel level. Restricted channels are only available after authentication using the queryauth URL. However, streams with restricted network but non restricted channel are public available.

This pull request changes the dataselect service to require authentication if a stream is restricted either on the network, station or channel level. Also the iteration is stopped early at network or station level if the restricted flag is found but no authentication was performed.

[andres-h]

I guess this would be needed for consistency. However, the previous behavior was intentional and this is also how ArcLink works, eg., it is OK to have non-restricted channels in restricted stations or non-restricted stations in restricted networks.

[gempa-jabe]

For the sake of consistency how would you suggest to continue? I don't think that defining different semantics for the same data model is desirable. Not sure if ArcLink should be the reference as it probably won't change anymore in future and would therefore block any progress in the fdsnws implementation.

[andres-h]

In principle I'm not against merging this PR.

Regarding semantics, do you think a non-restricted station in a restricted network is an error? It won't make sense after this patch is applied.

[gempa-stephan]

I guess this would be needed for consistency.

Yes. I think this is the intention for the includerestricted station request parameter.

However, the previous behavior was intentional and this is also how ArcLink works, eg., it is OK to have non-restricted channels in restricted stations or non-restricted stations in restricted networks.

This still could be archived by

• dropping the network and station level optimization check
• explicitly checking for station level restricted=false in case the network or the station is restricted

Of cause the same semantic needs to be implemented at the station service ... which will slow down queries because the network and station level iteration stop needs to be dropped here as well.

[gempa-jabe]

Regarding semantics, do you think a non-restricted station in a restricted network is an error? It won't make sense after this patch is applied.

That is why I am asking. It is like a 666 file in a 700 directory. Does it make sense or is it an error?

The station service already implements the same semantics. Have we ever questioned that?

I don't think that a non-restricted station in a restricted network is an error. It is just a flag for that particular station. If you open (restricted=false) the network then all flags of the contained stations would be taken into count instead of the network flag. Just like permissions in the filesystem.

For me it is just important to clearly define semantics for this restricted flag. If we can't do it in a generic way and it turns out that it is application specific then we would have to remove it from the inventory IMHO.

[andres-h]

OK, I think you can merge it.