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.

Sign up for GitHub

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

Jump to bottom

Version packages #2738

Merged
merged 1 commit into from
Aug 27, 2024
Merged

Version packages #2738

merged 1 commit into from
Aug 27, 2024

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Aug 22, 2024 •
edited
Loading

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@atproto/oauth-client@0.2.0

Minor Changes

  • #2714 d9ffa3c46 Thanks @matthieusieben! - The OAuthClient (and runtime specific sub-classes) no longer return @atproto/api Agent instances. Instead, they return OAuthSession instances that can be used to instantiate the Agent class.

  • #2734 dee817b6e Thanks @matthieusieben! - Remove "nonce" from authorization request

  • #2734 dee817b6e Thanks @matthieusieben! - Mandate the use of "atproto" scope

  • #2734 dee817b6e Thanks @matthieusieben! - Remove "openid" compatibility. The reason is that although we were technically "openid" compatible, ATProto identifiers are distributed identifiers. When a client relies on OpenID to authenticate users, it will use the auth provider in combination with the identifier to uniquely identify the user. Since ATProto identifiers are meant to be able to move from one provider to the other, OpenID compatibility could break authentication after a user was migrated to a different provider.

    The way OpenID compliant clients would adapt to this particularity would typically be to remove the provider + identifier combination and use the identifier alone. While this is indeed the right way to handle ATProto identifiers, it requires more work to avoid impersonation. In particular, when obtaining a user identifier, the client must verify that the issuer of the identity token is indeed the server responsible for that user. This mechanism being not enforced by the OpenID standard, OpenID compatibility could lead to security issues. For this reason, we decided to remove OpenID compatibility from the OAuth provider.

    Note that a trusted central authority could still offer OpenID compatibility by relying on ATProto's regular OAuth flow under the hood. This capability is out of the scope of this library.

  • #2714 d9ffa3c46 Thanks @matthieusieben! - Rename OAuthAgent into OAuthSession

  • #2714 d9ffa3c46 Thanks @matthieusieben! - Rename OAuthSession's request method to fetchHandler. The goal of this change is to allow OAuthSession to be used in order to instantiate XrpcClient by implementing the FetchHandlerObject interface.

Patch Changes

@atproto/oauth-client-browser@0.2.0

Minor Changes

  • #2714 d9ffa3c46 Thanks @matthieusieben! - The OAuthClient (and runtime specific sub-classes) no longer return @atproto/api Agent instances. Instead, they return OAuthSession instances that can be used to instantiate the Agent class.

  • #2734 dee817b6e Thanks @matthieusieben! - Remove "openid" compatibility. The reason is that although we were technically "openid" compatible, ATProto identifiers are distributed identifiers. When a client relies on OpenID to authenticate users, it will use the auth provider in combination with the identifier to uniquely identify the user. Since ATProto identifiers are meant to be able to move from one provider to the other, OpenID compatibility could break authentication after a user was migrated to a different provider.

    The way OpenID compliant clients would adapt to this particularity would typically be to remove the provider + identifier combination and use the identifier alone. While this is indeed the right way to handle ATProto identifiers, it requires more work to avoid impersonation. In particular, when obtaining a user identifier, the client must verify that the issuer of the identity token is indeed the server responsible for that user. This mechanism being not enforced by the OpenID standard, OpenID compatibility could lead to security issues. For this reason, we decided to remove OpenID compatibility from the OAuth provider.

    Note that a trusted central authority could still offer OpenID compatibility by relying on ATProto's regular OAuth flow under the hood. This capability is out of the scope of this library.

Patch Changes

@atproto/oauth-client-node@0.1.0

Minor Changes

  • #2714 d9ffa3c46 Thanks @matthieusieben! - The OAuthClient (and runtime specific sub-classes) no longer return @atproto/api Agent instances. Instead, they return OAuthSession instances that can be used to instantiate the Agent class.

  • #2734 dee817b6e Thanks @matthieusieben! - Remove "openid" compatibility. The reason is that although we were technically "openid" compatible, ATProto identifiers are distributed identifiers. When a client relies on OpenID to authenticate users, it will use the auth provider in combination with the identifier to uniquely identify the user. Since ATProto identifiers are meant to be able to move from one provider to the other, OpenID compatibility could break authentication after a user was migrated to a different provider.

    The way OpenID compliant clients would adapt to this particularity would typically be to remove the provider + identifier combination and use the identifier alone. While this is indeed the right way to handle ATProto identifiers, it requires more work to avoid impersonation. In particular, when obtaining a user identifier, the client must verify that the issuer of the identity token is indeed the server responsible for that user. This mechanism being not enforced by the OpenID standard, OpenID compatibility could lead to security issues. For this reason, we decided to remove OpenID compatibility from the OAuth provider.

    Note that a trusted central authority could still offer OpenID compatibility by relying on ATProto's regular OAuth flow under the hood. This capability is out of the scope of this library.

Patch Changes

@atproto/oauth-provider@0.2.0

Minor Changes

  • #2734 dee817b6e Thanks @matthieusieben! - Remove "nonce" from authorization request

  • #2734 dee817b6e Thanks @matthieusieben! - Mandate the use of "atproto" scope

  • #2734 dee817b6e Thanks @matthieusieben! - Remove "openid" compatibility. The reason is that although we were technically "openid" compatible, ATProto identifiers are distributed identifiers. When a client relies on OpenID to authenticate users, it will use the auth provider in combination with the identifier to uniquely identify the user. Since ATProto identifiers are meant to be able to move from one provider to the other, OpenID compatibility could break authentication after a user was migrated to a different provider.

    The way OpenID compliant clients would adapt to this particularity would typically be to remove the provider + identifier combination and use the identifier alone. While this is indeed the right way to handle ATProto identifiers, it requires more work to avoid impersonation. In particular, when obtaining a user identifier, the client must verify that the issuer of the identity token is indeed the server responsible for that user. This mechanism being not enforced by the OpenID standard, OpenID compatibility could lead to security issues. For this reason, we decided to remove OpenID compatibility from the OAuth provider.

    Note that a trusted central authority could still offer OpenID compatibility by relying on ATProto's regular OAuth flow under the hood. This capability is out of the scope of this library.

Patch Changes

@atproto/api@0.13.4

Patch Changes

  • #2714 d9ffa3c46 Thanks @matthieusieben! - Drop use of AtpBaseClient class

  • #2714 d9ffa3c46 Thanks @matthieusieben! - Expose the CredentialSession class that can be used to instantiate both Agent and XrpcClient, while internally managing credential based (username/password) sessions.

  • bbca17bc5 Thanks @matthieusieben! - Deprecate Agent.accountDid in favor of Agent.assertDid

  • #2737 a8e1f9000 Thanks @estrattonbailey! - Add threadgate: ThreadgateView to response from getPostThread

  • #2714 d9ffa3c46 Thanks @matthieusieben! - Agent is no longer an abstract class. Instead it can be instantiated using object implementing a new SessionManager interface. If your project extends Agent and overrides the constructor or any method implementations, consider that you may want to call them from super.

  • Updated dependencies [d9ffa3c46, d9ffa3c46, d9ffa3c46]:

    • @atproto/xrpc@0.6.1

@atproto/aws@0.2.3

Patch Changes

  • Updated dependencies [ebb318325]:
    • @atproto/crypto@0.4.1
    • @atproto/repo@0.4.3

@atproto/bsky@0.0.79

Patch Changes

@atproto/crypto@0.4.1

Patch Changes

@atproto/dev-env@0.3.45

Patch Changes

@atproto/identity@0.4.1

Patch Changes

  • Updated dependencies [ebb318325]:
    • @atproto/crypto@0.4.1

@atproto/oauth-types@0.1.4

Patch Changes

@atproto/ozone@0.1.41

Patch Changes

@atproto/pds@0.4.54

Patch Changes

@atproto/repo@0.4.3

Patch Changes

  • Updated dependencies [ebb318325]:
    • @atproto/crypto@0.4.1

@atproto/xrpc@0.6.1

Patch Changes

@atproto/xrpc-server@0.6.3

Patch Changes

@github-actions github-actions bot force-pushed the changeset-release/main branch 5 times, most recently from 7269d62 to f29d98c Compare August 26, 2024 07:04
@github-actions github-actions bot force-pushed the changeset-release/main branch from f29d98c to f1fd0bc Compare August 27, 2024 18:00
@devinivy devinivy merged commit a1d8c77 into main Aug 27, 2024
@devinivy devinivy deleted the changeset-release/main branch August 27, 2024 18:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
1 participant
@devinivy