crotwell
commented
1 year ago I guess a question would be is it ok to leak information on the mere existence of AUTH-only channels? If that is a concern, then the "does not exist" is the right thing to do.
An additional problem is that for a long running connection, an AUTH channel that matches the SELECT may only come into existence after data has begun flowing. It would be too late at that point for the server to send an error.
Perhaps instead something could be folded into the INFO command, so a client could determine the existence of restricted stations or streams? Maybe that also provides an easier way for the server to withhold that info if it feels the need?
Another idea would be to make AUTH mandatory. Implementations could provide a no-password "guest" user for public access. But by making AUTH required, there is no case of "oops I didn't log in and so I missed data".
andres-h
The draft states: "If a user does not have access to a station, then all commands SHOULD behave as if the station does not exist."
From a user point of perspective, there may be cases where it could be favourable to have a meaningful error message such as "authentication required". People may rely on scripts and may not notice that some of the data is missing. I am aware that in the case of wildcard requests, some streams might be available to the user while others may not and that in this case, it may be more useful for some users if the server just silently drops requests for which they are not authenticated properly.
I suggest to add the possibility to set a flag in the SELECT command on whether the server should behave as stated in the draft or on whether an error message should pop up instead. This way, a user would be informed that he or she should provide credentials or ask for them instead of unknowingly missing some data.
Some other ideas which would break the current simple semantics of request and answer would be to give a message on which channels have been successfully selected and which channels need authentication and to serve the data after this instead of just answering "OK".