Skip to content

Wip #241

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

Closed
wants to merge 69 commits into from
Closed

Wip #241

wants to merge 69 commits into from

Conversation

anubhav756
Copy link
Contributor

No description provided.

anubhav756 added 30 commits May 16, 2025 16:39
This change introduces a warning that is displayed immediately before a tool invocation if:
1. The invocation includes an authentication header.
2. The connection is being made over non-secure HTTP.

> [!IMPORTANT]
The purpose of this warning is to alert the user to the security risk of sending credentials over an unencrypted channel and to encourage the use of HTTPS.
This aligns with the async client's `load_toolset` method.
This PR addresses the scenario where a user provides both `auth_tokens` and `auth_headers`, both of which are deprecated arguments.

### Problem
Previously, if a user provided both `auth_tokens` and `auth_headers`, the authentication tokens from `auth_headers` were prioritized. This created an inconsistent behavior, especially considering that `auth_tokens` was deprecated more recently than `auth_headers`.

### Solution
This change shifts the precedence to `auth_tokens`. Now, if both `auth_tokens` and `auth_headers` are present, only the authentication tokens specified in `auth_tokens` will be considered.

### Reasoning
1.  `auth_tokens` was deprecated more recently than `auth_headers`. Prioritizing the more recently deprecated argument provides a clearer signal to users about the intended deprecation path and guides them towards the recommended, non-deprecated args.
2.  We opted *not* to merge authentication tokens from both deprecated arguments. Merging could lead to increased user confusion and inadvertently encourage continued reliance on these legacy features, hindering migration efforts.
3.  This approach aligns with our broader deprecation strategy. For instance, when a user provides `auth_token_getters` (the current recommended approach) alongside a deprecated argument like `auth_tokens`, `auth_token_getters` takes precedence and overrides the deprecated argument. This PR extends that "latest argument wins" principle to the deprecated arguments themselves, ensuring consistent behavior.
anubhav756 added 20 commits May 16, 2025 17:00
…lity

This PR addresses a breaking change introduced by the removal of `add_auth_token(s)` methods in #182. To ensure backward compatibility and facilitate a smoother upgrade path, these methods are now reintroduced but explicitly marked as **deprecated**. Users are encouraged to migrate to the new `add_auth_token_getter(s)` methods instead.

> [!NOTE]
> The `strict` flag in the deprecated methods are not used anymore since the functionality of the `strict` flag has been changed (see #205 for more details).
@anubhav756 anubhav756 requested a review from a team as a code owner May 16, 2025 12:09
@anubhav756 anubhav756 marked this pull request as draft May 16, 2025 12:09
@anubhav756 anubhav756 force-pushed the WIP branch 3 times, most recently from 79b067a to 0fc894b Compare May 16, 2025 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants