GNOME Bugzilla – Bug 702548
problem with authentication for tunneled clients
Last modified: 2018-11-03 15:37:53 UTC
When clients tunnel rtsp over http, the gst-rtsp-server is handed a socket in gst_rtsp_server_transfer_connection. The authentication is however not handled correctly, it will be handled just like for non-tunneled clients and as far as I understand there will be no more authentication after the tunnel has been set up? If this is the case, that rtsp-server should not bother itself with authentication in the tunneling case, then adding: gst_rtsp_client_set_auth (client, NULL); in gst_rtsp_server_transfer_connection might be sufficient (works for me, but I cannot judge if there are more use cases).
I realize there are cases where you want to handle authentication as well (where the application handing the socket doens't know or care about the authentication scheme), this is however not our case. Perhaps the solution is to add gboolean authorized to the arguments of gst_rtsp_server_transfer_connection and if set, then we disable authentication for that client as in my last comment?
(In reply to comment #1) > I realize there are cases where you want to handle authentication as well > (where the application handing the socket doens't know or care about the > authentication scheme), this is however not our case. Perhaps the solution is > to add gboolean authorized to the arguments of > gst_rtsp_server_transfer_connection and if set, then we disable authentication > for that client as in my last comment? You can use gst_rtsp_client_set_auth() to disable the authentication, or set a different one if you want to handle this client differently.
I know I can use the gst_rtsp_client_set_auth function. My question is if it's ok to modify the gst_rtsp_server_transfer_connection to include a boolean wheter or not to use gst_rtsp_client_set_auth to disable authentication for that client.
(In reply to comment #3) > I know I can use the gst_rtsp_client_set_auth function. My question is if it's > ok to modify the gst_rtsp_server_transfer_connection to include a boolean > wheter or not to use gst_rtsp_client_set_auth to disable authentication for > that client. I don't like the boolean that sets the auth to NULL. I think it should be something less dramatic. Some options: 1) add auth to the transfer function to use as the auth manager for this transfered connection. A little weird, you would want to use the same auth manager as the other clients, maybe with some relaxed or different behaviour. 2) Mark the client as being 'authenticated' and let the auth manager skip the password setup and checks. It sounds conceptually better. You would need a way mark the client state somehow, maybe add a vmethod when a client is transfered? again, it should still be possible to do the auth over the tunneled connection. You can now take the client-connected signal, check if the connection is tunneled and set a NULL auth, if you want.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/2.