Skip to content

Add spec-driven Swagger auth controls#1779

Open
krowvin wants to merge 3 commits into
developfrom
swagger-auth-controls
Open

Add spec-driven Swagger auth controls#1779
krowvin wants to merge 3 commits into
developfrom
swagger-auth-controls

Conversation

@krowvin

@krowvin krowvin commented Jun 11, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Update the GUI to use Groundwork Water auth helpers for Swagger UI login
  • Select the custom login method from the generated OpenAPI security schemes
  • Add a login mode dropdown so users can switch between the custom login flow and Swagger's built-in Authorize controls
  • Support localhost development by falling back to local Keycloak direct-grant auth when CWMSLogin is advertised but not reachable (It was showing in the security controls response)
  • Fix localhost Keycloak dev redirect and healthcheck behavior

Validation

  • npx.cmd eslint src/pages/swagger-ui/index.jsx --ext js,jsx --report-unused-disable-directives --max-warnings 0
  • npm.cmd run build
  • Tested manually on localhost against local CDA instance

Screenshots

With "CWBI Login" selected the locks on the swagger UI are not shown. The hope is to not add login confusion by default. While still allowing the option to authenticate via other means (API key/etc)

image image
  • AI Tools Used

@krowvin krowvin requested a review from MikeNeilson June 11, 2026 18:37

@krowvin krowvin left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Few thoughts of my own with these changes

background: #fafafa;
}

.swagger-auth-bar {

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I was wondering if this should be tailwind css? Preference?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What ever is inline with GWW and its usages by USACE?

Comment thread cda-gui/package.json
"dependencies": {
"@tanstack/react-query": "^5.64.1",
"@usace-watermanagement/groundwork-water": "^3.3.1",
"@usace-watermanagement/groundwork-water": "^3.9.0",

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

older GWW only supported direct grant

Comment thread cda-gui/vite.config.js
proxy: {
"^/cwms-data/timeseries/.*": {
target: env.CDA_API_ROOT,
"/cwms-data/timeseries": {

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I debated doing one single wildcard for the localhost proxy here

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

May as well so everything can be tested correctly locally by default.

"https://localhost:5010/*",
"http://localhost:*"
"http://localhost:*",
"http://127.0.0.1:*"

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Sometimes it'll launch in loopback, othertimes it's localhost. Figured we'd have both.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yep, 127.0.0.1 is the ostensibly "correct" way, but in local development mode having both will make life easier.

@krowvin krowvin marked this pull request as ready for review June 11, 2026 18:39

@MikeNeilson MikeNeilson left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Sorry for the delay, thought the review had actually submitted thursday and it had not.

background: #fafafa;
}

.swagger-auth-bar {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What ever is inline with GWW and its usages by USACE?

Comment thread cda-gui/vite.config.js
proxy: {
"^/cwms-data/timeseries/.*": {
target: env.CDA_API_ROOT,
"/cwms-data/timeseries": {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

May as well so everything can be tested correctly locally by default.

"https://localhost:5010/*",
"http://localhost:*"
"http://localhost:*",
"http://127.0.0.1:*"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yep, 127.0.0.1 is the ostensibly "correct" way, but in local development mode having both will make life easier.

background: #912018;
}

.swagger-ui-host:not(.swagger-login-mode) .swagger-ui .auth-wrapper {

@rma-psmorris rma-psmorris Jun 15, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I don't think this should be done as the lock icon is informative as to what authentication is required by the endpoint. Swagger also doesn't have the best UI for their auth state (see swagger-api/swagger-ui#4402).

  • No lock icon: the endpoint is public. Authentication is not involved with the operation.
  • Gray unlocked lock icon: authentication is optional. The endpoint allows anonymous access, but also accepts authenticated requests if credentials are provided.
  • Black locked lock icon: authentication is required. The endpoint cannot be called successfully without valid credentials.

The change you are implementing here by not displaying the lock icon suggests that all endpoints are public.
Also, CDA does not correctly define Swagger icon state for black locked lock icons -- but that is a separate issue (that I'm checking on to see if it needs an issue to be created).

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

I'm good to remove the drop-down and leave a simple login button that logs you in via AAA or KeyCloak depending on the swagger spec.

@MikeNeilson

I'll do this unless you have thoughts on why we should leave locks out.

My thinking was to have users opt into the swagger locks if they want this route of auth. Intenteded for internal use. But I realize that won't always be the case.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The locks should stay. Definitely interested in the no/gray/black though. Long term there will be items that won't show up from GETs unless authenticated with the new authorization work.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Here is the existing lock issue: #1118

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.

3 participants