conn->user is wrong for HTTP #6542
Assignees
Labels
Comments
bagder
added a commit
that referenced
this issue
Jan 29, 2021
HTTP auth "accidentally" worked before this cleanup since the code would always overwrite the connection credentials with the credentials from the most recent transfer and since HTTP auth is typically done first thing, this has not been an issue. It was still wrong and subject to possible race conditions or future breakage if the sequence of functions would change. The data.set.str[] strings MUST remain unmodified exactly as set by the user, and the credentials to use internally are instead set/updated in state.aptr.* Fixes #6542
bagder
added a commit
that referenced
this issue
Feb 8, 2021
HTTP auth "accidentally" worked before this cleanup since the code would always overwrite the connection credentials with the credentials from the most recent transfer and since HTTP auth is typically done first thing, this has not been an issue. It was still wrong and subject to possible race conditions or future breakage if the sequence of functions would change. The data.set.str[] strings MUST remain unmodified exactly as set by the user, and the credentials to use internally are instead set/updated in state.aptr.* Fixes #6542 Closes #6545
bagder
added a commit
that referenced
this issue
Feb 10, 2021
HTTP auth "accidentally" worked before this cleanup since the code would always overwrite the connection credentials with the credentials from the most recent transfer and since HTTP auth is typically done first thing, this has not been an issue. It was still wrong and subject to possible race conditions or future breakage if the sequence of functions would change. The data.set.str[] strings MUST remain unmodified exactly as set by the user, and the credentials to use internally are instead set/updated in state.aptr.* Fixes #6542 Closes #6545
bagder
added a commit
that referenced
this issue
Feb 12, 2021
HTTP auth "accidentally" worked before this cleanup since the code would always overwrite the connection credentials with the credentials from the most recent transfer and since HTTP auth is typically done first thing, this has not been an issue. It was still wrong and subject to possible race conditions or future breakage if the sequence of functions would change. The data.set.str[] strings MUST remain unmodified exactly as set by the user, and the credentials to use internally are instead set/updated in state.aptr.* Fixes #6542 Closes #6545
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When a connection is created the
conn->useris copied from the transfer struct. This is for connections that have a single user for the duration of the connection. The user name is then associated with that connection.For HTTP (and RTSP), the user name (and password etc) is done per transfer and not just per connection. As such, using
conn->userandconn->passwdin HTTP code is considered wrong.It still (mostly) works in the code right now because the credentials are used immediately after the creation of or early use of the connection, before it gets the chance to get reassigned by another transfer that can reuse the same connection - potentially multiplexed.
It is probably an error waiting to happen if we change the order of things or if the use of the credentials for a transfer would be delayed if or the order of events would be changed.
The text was updated successfully, but these errors were encountered: