Skip to content

chore: local dev HTTPS on :5180 + major dep bumps#20

Merged
hoangsnowy merged 2 commits into
mainfrom
chore/local-dev-https-and-deps
May 30, 2026
Merged

chore: local dev HTTPS on :5180 + major dep bumps#20
hoangsnowy merged 2 commits into
mainfrom
chore/local-dev-https-and-deps

Conversation

@hoangsnowy
Copy link
Copy Markdown
Owner

Summary

  • Switch local dev Web from HTTP to HTTPS on :5180 (Aspire WithHttpsEndpoint, realm import redirectUris + webOrigins updated; KC stays HTTP 8080).
  • Bump packages: ApplicationInsights.AspNetCore 2.23→3.1.2, Octokit 13→14, xunit.v3 1.1.0→3.2.2, Microsoft.NET.Test.Sdk 17.13→18.6.0, coverlet.collector 6.0.4→10.0.1, Azure.Identity 1.14→1.21, Scalar.AspNetCore 2.6→2.14.14, System.IdentityModel.Tokens.Jwt 8.3→8.18, xunit.runner.visualstudio 3.0.2→3.1.5, Aspire.Hosting.Keycloak preview rolled to 13.3.5-preview.1.26270.6.
  • Zero source changes required for any of the majors.

Decisions

  • JsonSchema.Net stays pinned 7.*. Bumping to 9.x reshapes EvaluationResults and needs a JsonSchemaValidator rewrite — separate follow-up.
  • KC stays HTTP 8080 because the realm issuer claim is baked there and Web (HTTPS) → KC (HTTP) browser-side redirect works for OIDC code flow without mixed-content cookie issues.

Local-dev follow-up (after merge)

  • dotnet dev-certs https --trust if not already trusted.
  • Clear or recreate the Keycloak data volume so the new redirectUris apply (realm import only fires on a fresh volume).

Test plan

  • dotnet build AgentOs.slnx -c Release clean
  • dotnet test AgentOs.slnx -c Release → 226 passed, 22 skipped (live-LLM + browser E2E)
  • CI green
  • Manual: AppHost dotnet run --project infra/AgentOs.AppHost → Web on https://localhost:5180, sign-in round-trip works

🤖 Generated with Claude Code

hoangsnowy and others added 2 commits May 30, 2026 12:30
AppHost pins Web to https:5180 (WithHttpsEndpoint) and the realm import
updates redirectUris + webOrigins to match. Keycloak stays on HTTP 8080
for the local Aspire dev loop. Existing KC data volume must be cleared
(or the realm reimported) so the new client URIs take effect.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Majors: Microsoft.ApplicationInsights.AspNetCore 2.23 -> 3.1.2,
Octokit 13 -> 14, xunit.v3 1.1.0 -> 3.2.2, Microsoft.NET.Test.Sdk
17.13 -> 18.6.0, coverlet.collector 6.0.4 -> 10.0.1. Minors:
Azure.Identity 1.14 -> 1.21, Scalar.AspNetCore 2.6 -> 2.14.14,
System.IdentityModel.Tokens.Jwt 8.3 -> 8.18, xunit.runner.visualstudio
3.0.2 -> 3.1.5. Aspire.Hosting.Keycloak preview rolled to
13.3.5-preview.1.26270.6 (matches the stable 13.3.5 core line).

No source changes required: existing AddApplicationInsightsTelemetry()
and Octokit GitHubClient ctor surfaces are unchanged at the new majors,
and xunit.v3's public test API stayed stable across the 1.x -> 3.x
jump. JsonSchema.Net stays pinned at 7.* deliberately; bumping to 9.x
reshapes EvaluationResults and needs a JsonSchemaValidator rewrite,
tracked as a separate follow-up.

Verified: dotnet build (Release) + dotnet test green (226 pass, 22
skipped — live-LLM + browser E2E skips).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@hoangsnowy hoangsnowy merged commit 7da13f5 into main May 30, 2026
1 check passed
hoangsnowy added a commit that referenced this pull request May 30, 2026
The Aspire dashboard mixed schemes — Web was HTTPS (:5180, PR #20) while
the API still showed http://localhost:5080. Flip the API to HTTPS too so
every .NET app endpoint in the AppHost is HTTPS and the documented links
match.

- src/AgentOs.Api/Properties/launchSettings.json: rename the launch
  profile http -> https, applicationUrl https://localhost:5080. Aspire
  reads the profile, so the api resource now exposes an HTTPS endpoint
  and the dashboard link is https://localhost:5080/scalar/v1. Uses the
  same ASP.NET dev cert as Web (dotnet dev-certs https --trust).
- Docs (README, docs/SETUP.md, CLAUDE.md): update the Scalar / health /
  openapi / curl example URLs to https.
- Code defaults that point at the local API follow it to https so they
  aren't broken-by-default against an https-only API:
  RemoteAgent REMOTE_AGENT_HUB default and the HttpPipelineClient
  Api:BaseUrl fallback. Both remain environment-overridable.

Keycloak (:8080) and MailHog (:8025) intentionally stay HTTP — see the
PR description. On localhost, putting KC behind a self-signed HTTPS cert
breaks the backend OIDC metadata fetch (HttpClient rejects the untrusted
cert) for zero security benefit; MailHog has no native TLS.

Build clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
hoangsnowy added a commit that referenced this pull request May 30, 2026
…cy (#23)

The Aspire dashboard mixed schemes — Web was HTTPS (:5180, PR #20) while
the API still showed http://localhost:5080. Flip the API to HTTPS too so
every .NET app endpoint in the AppHost is HTTPS and the documented links
match.

- src/AgentOs.Api/Properties/launchSettings.json: rename the launch
  profile http -> https, applicationUrl https://localhost:5080. Aspire
  reads the profile, so the api resource now exposes an HTTPS endpoint
  and the dashboard link is https://localhost:5080/scalar/v1. Uses the
  same ASP.NET dev cert as Web (dotnet dev-certs https --trust).
- Docs (README, docs/SETUP.md, CLAUDE.md): update the Scalar / health /
  openapi / curl example URLs to https.
- Code defaults that point at the local API follow it to https so they
  aren't broken-by-default against an https-only API:
  RemoteAgent REMOTE_AGENT_HUB default and the HttpPipelineClient
  Api:BaseUrl fallback. Both remain environment-overridable.

Keycloak (:8080) and MailHog (:8025) intentionally stay HTTP — see the
PR description. On localhost, putting KC behind a self-signed HTTPS cert
breaks the backend OIDC metadata fetch (HttpClient rejects the untrusted
cert) for zero security benefit; MailHog has no native TLS.

Build clean.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@hoangsnowy hoangsnowy deleted the chore/local-dev-https-and-deps branch May 30, 2026 10:51
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.

1 participant