Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

conn->user is wrong for HTTP #6542

Closed
bagder opened this issue Jan 28, 2021 · 0 comments
Closed

conn->user is wrong for HTTP #6542

bagder opened this issue Jan 28, 2021 · 0 comments

Comments

@bagder
Copy link
Member

@bagder bagder commented Jan 28, 2021

When a connection is created the conn->user is 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->user and conn->passwd in 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.

@bagder bagder self-assigned this Jan 28, 2021
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
@bagder bagder closed this in 46620b9 Feb 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

1 participant