Skip to content

Logto#1241

Open
axies20 wants to merge 16 commits intoCommunityToolkit:mainfrom
axies20:Logto
Open

Logto#1241
axies20 wants to merge 16 commits intoCommunityToolkit:mainfrom
axies20:Logto

Conversation

@axies20
Copy link
Copy Markdown
Contributor

@axies20 axies20 commented Mar 27, 2026

Closes #<ISSUE_NUMBER>

PR Checklist

  • Created a feature/dev branch in your fork (vs. submitting directly from a commit on main)
  • Based off latest main branch of toolkit
  • PR doesn't include merge commits (always rebase on top of our main, if needed)
  • New integration
    • Docs are written
    • Added description of major feature to project description for NuGet package (4000 total character limit, so don't push entire description over that)
  • Tests for the changes have been added (for bug fixes / features) (if applicable)
  • Contains NO breaking changes
  • Every new API (including internal ones) has full XML docs
  • Code follows all style conventions

Other information

- Introduced `CommunityToolkit.Aspire.Hosting.Logto` project for integrating Logto with PostgreSQL and Redis.
- Added extension methods for configuring Logto containers, health checks, and resource dependencies.
- Created test projects for validating Logto container configuration and health checks.
- Added example projects under `examples/logto` showcasing Logto integration with PostgreSQL and Redis.
- Updated solution file and package references to include the new Logto project.
- Introduced `CommunityToolkit.Aspire.Hosting.Logto.Client` project for integrating Logto client configuration.
- Added `LogtoClientBuilder` for seamless setup of Logto client services in `IHostApplicationBuilder`.
- Implemented connection string helper for parsing Logto connection strings.
- Updated solution and centralized package references to include the new project.
- Introduced `CommunityToolkit.Aspire.Hosting.Logto.ClientApi` under `examples/logto` to demonstrate Logto client integration.
- Added project configuration files (`Program.cs`, `appsettings.json`, `launchSettings.json`) for application setup.
- Renamed `AddLogtoClient` to `AddLogtoSDKClient` in `LogtoClientBuilder`.
- Updated solution and centralized package references to include the new example project and dependencies.
- Introduced a new test project `CommunityToolkit.Aspire.Hosting.Logto.Client.Tests` for validating Logto client behavior.
- Added integration and unit tests for `LogtoClientBuilder` and `LogtoConnectionStringHelper`.
- Implemented OIDC authentication and JWT bearer support in `LogtoClientBuilder`.
- Extended `Program.cs` in `ClientApi` example with authentication routes (`/me`, `/signin`, `/signout`).
- Updated dependencies and centralized package references for added functionalities.
- Modified project and solution files to include updated references.
- Updated method names from `AddLogtoSDKClient` to `AddLogtoOIDC` for better alignment with OIDC usage.
- Enhanced `AddLogtoOIDC` and `AddLogtoJwtBearer` methods to support additional configuration options.
- Added `Microsoft.Extensions.DependencyInjection.Abstractions` package reference to support service registration.
- Updated tests to reflect the method renaming and new configuration capabilities.
- Extended `Program.cs` in the ClientApi example to include `UseAuthentication` and `UseAuthorization`.
- Improved consistency and readability of XML documentation across updated methods.
- Centralized package references for additional dependencies in `Directory.Packages.props`.
- Changed the `ClientApi` project to `ClientOIDC` for better alignment with OIDC standards.
- Updated method signatures in `LogtoClientBuilder` to use `appIndeficator` instead of `appId` and support multiple audience identifiers.
- Improved XML documentation consistency for updated methods.
- Adjusted solution, project references, and configuration files to reflect the renaming and API changes.
- Introduced `CommunityToolkit.Aspire.Hosting.Logto.ClientJWT` project under `examples/logto` to demonstrate Logto JWT authentication.
- Configured authentication and authorization middleware with Logto's JWT Bearer scheme in `Program.cs`.
- Added example routes (`/secure` and `/tokens`) for testing secured endpoint access and token retrieval.
- Updated `AppHost` to include `ClientJWT` project as a dependency.
- Improved XML documentation for `AddLogtoJwtBearer` methods, including updated parameter descriptions and exception handling.
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Mar 27, 2026

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.sh | bash -s -- 1241

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.ps1) } 1241"

Copy link
Copy Markdown
Member

@aaronpowell aaronpowell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some questions and comments but the main thing is that the client project shouldn't have Hosting in the name (or namespace).

builder.AddServiceDefaults();

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddLogtoJwtBearer("logto", "http://localhost:5072/",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the endpoint come from Aspire?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does. logto is the Aspire resource name, so the endpoint is resolved from Aspire via .WithReference(logto). The second parameter is the JWT appIdentification/audience, not the Logto endpoint, so I updated the sample to make that clearer.

Comment on lines +11 to +12
config.AppId = "s6zda5bqn1qlsjzaiklqn";
config.AppSecret = "Df77aDt13MG3nSTgo8eKZP2HdeSfbed0";
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume these are things that could come from Aspire

Copy link
Copy Markdown
Contributor Author

@axies20 axies20 Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not directly from Aspire today. These values are Logto client credentials, so they need to come from a Logto application registration first. Aspire can pass them through configuration/secrets, but it doesn't create the Logto application automatically.

It would be possible to automate that through the Logto Management API, but that would add a separate provisioning workflow, which felt out of scope for this sample.

<PropertyGroup>
<Description>.NET Aspire hosting extensions for Logto (includes PostgreSQL and Redis integration).</Description>
<AdditionalPackageTags>logto redis postgres hosting extensions</AdditionalPackageTags>
<IsPreview>true</IsPreview>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we marking this as preview? Should we be putting Experimental attributes in?

Comment on lines +42 to +44
builderWithResource
.WithEntrypoint("sh")
.WithArgs("-c", "npm run cli db seed -- --swe && npm start");
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it could be very opaque to the user that the entrypoint is being overridden, what's the reason we do it?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We override the entrypoint because Logto requires the DB seed step before the app starts in our Aspire scenario, otherwise the container doesn't come up in a usable state. I agree this is not obvious from AddLogtoContainer(), so I can make it explicit either by documenting it clearly or by moving it behind an opt-in method like WithDatabaseSeeding()/WithSeededStartup().

Comment on lines +23 to +32
<<<<<<< Logto
<PackageVersion Include="Logto.AspNetCore.Authentication" Version="0.2.0" />
<PackageVersion Include="Microsoft.AspNetCore.Authentication" Version="2.3.0" />
<PackageVersion Include="Microsoft.AspNetCore.Authentication.JwtBearer" Version="10.0.0" />
<PackageVersion Include="Microsoft.AspNetCore.Authentication.OpenIdConnect" Version="10.0.0" />
<PackageVersion Include="Microsoft.AspNetCore.Http.Abstractions" Version="2.3.0" />
<PackageVersion Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="10.0.0" />
=======
<PackageVersion Include="AspNetCore.HealthChecks.Network" Version="9.0.0" />
>>>>>>> main
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think this is a merge gone bad

axies20 and others added 7 commits March 30, 2026 14:29
…ommunityToolkit.Aspire.Hosting.Logto.AppHost.csproj

Co-authored-by: Aaron Powell <me@aaron-powell.com>
…kit.Aspire.Hosting.Logto.Client.csproj

Co-authored-by: Aaron Powell <me@aaron-powell.com>
- Upgraded `Aspire.AppHost.Sdk` from `13.0.0` to `13.2.0` in `examples/logto/CommunityToolkit.Aspire.Hosting.Logto.AppHost.csproj`.
- Added `Microsoft.AspNetCore.Authentication.JwtBearer` and `Microsoft.AspNetCore.Authentication.OpenIdConnect` package versions to `Directory.Packages.props`.
…o JWT configuration

- Replaced hardcoded API audience with a `const` string in `Program.cs` for improved readability and maintainability.
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