-
Notifications
You must be signed in to change notification settings - Fork 1
fix username/password auth #81
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
base: 12-13-typegen_web_ui
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
e5e8d9c to
51287c9
Compare
@proofkit/better-auth
@proofkit/cli
create-proofkit
@proofkit/fmdapi
@proofkit/fmodata
@proofkit/typegen
@proofkit/webviewer
commit: |
| "username" in envNames.auth | ||
| ) { | ||
| addTypeGuardStatements(sourceFile, { | ||
| envVarName: envNames.auth?.username ?? defaultEnvNames.username, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Generated code requires all auth env vars unnecessarily
The type guard generation now adds throw statements for apiKey, username, AND password environment variables whenever envNames.auth is an object. Previously, it only added guards for the specific auth method being used. Now, if a user configures only API key authentication, the generated client will throw errors for missing FM_USERNAME and FM_PASSWORD env vars that aren't actually needed, making the generated code unusable.
packages/typegen/src/typegen.ts
Outdated
| envNames?.auth && "password" in envNames.auth | ||
| ? (envNames.auth.password ?? defaultEnvNames.password) | ||
| : defaultEnvNames.password, | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Auth object structure always causes OttoAdapter selection
The auth object passed to buildLayoutClient now always includes apiKey with a default value, regardless of the authentication method configured. This breaks the adapter selection logic in buildLayoutClient.ts (lines 27-35), which uses "apiKey" in envNames.auth to choose between OttoAdapter and FetchAdapter. Since apiKey is now always present, OttoAdapter is always imported and FetchAdapter is never used, completely breaking username/password authentication.
9045be0 to
7d472d4
Compare
|
Cursor Agent can help with this pull request. Just |
d180094 to
6f5e5f6
Compare
Note
Improves env var/auth resolution (username/password), adds alias-aware OData codegen and import preservation, and upgrades UI tables/fields editors (sticky headers, scrolling, bulk include/exclude) with new tests and snapshots.
envNames.authshape and read/validate all auth envs (API key or username/password) acrossgetEnvValues, server client creation, and layout client guards.OttoAdaptervsFetchAdapterbased on provided creds.envNames.authschema to a single object with optionalapiKey,username,password.OttoAdaptervsFetchAdapterselection; update zod import snapshot.Written by Cursor Bugbot for commit d180094. This will update automatically on new commits. Configure here.