使用 Coding Agent 接入单点登录
在 Coding Agent 中打开你的项目，然后复制并发送下面的 Prompt。Agent 会检查现有登录系统，实现服务端 JWT 跳转，添加产品入口，并分别验证用户已登录和未登录时的访问流程。
不要把 FeedLog SSO 密钥写进 Prompt，也不要粘贴到对话中。Agent 会告诉你如何把密钥配置为服务端环境变量。
复制 Prompt
txt
Integrate FeedLog single sign-on into this product. Work directly in the current repository: inspect the codebase, make the required changes, run the relevant checks, and verify the integration as far as the available environment allows. Do not stop at providing instructions or example code.
Communicate with me in the language I use. Follow all repository-level instructions, including AGENTS.md, CLAUDE.md, contribution guides, and existing coding conventions.
Official documentation:
- SSO and JWT signing: https://help.feedlog.ai/developers/sso
Read the official documentation before editing if network access is available. If it is unavailable, continue using the requirements below. If the current official documentation conflicts with this prompt, follow the documentation and mention the difference in your final report.
## Goal
Add a user-facing FeedLog link backed by a server-side redirect that carries the current user's identity only when the user is already signed in to this product.
The required behavior is:
- signed in: issue a short-lived FeedLog JWT and redirect through FeedLog's `/api/sso/jwt` endpoint;
- signed out: redirect directly to the same FeedLog destination without a JWT;
- authentication lookup failure: handle it as an operational error according to project conventions, not as a confirmed sign-out.
SSO is an identity enhancement, not a requirement for visiting FeedLog. Do not force a signed-out user to sign in, do not open the application's sign-in UI, and do not block anonymous access to FeedLog.
This task is for browser handoff. Do not install `@feedlog/widget` or implement the widget token-exchange flow unless I ask for it separately.
## Inspect the project first
Before asking me for paths or implementation details, inspect the repository and determine:
- the frontend and backend frameworks, versions, package manager, and application entry points;
- how the server authenticates a request and distinguishes a confirmed signed-out state from an authentication-system failure;
- how API routes, server actions, redirects, and middleware are organized;
- where the product's Feedback, Feature requests, Help, Support, Roadmap, or Changelog links live;
- how external URLs, environment variables, and deployment secrets are managed;
- how navigation labels are translated and how desktop and mobile navigation are kept consistent;
- the existing lint, typecheck, test, build, and browser-test commands.
Reuse the project's existing authentication, API, configuration, navigation, localization, and error-handling patterns. Do not introduce another authentication system or perform an unrelated authentication refactor.
Ask a focused question only when required information cannot be discovered from the repository.
## Handle incomplete repositories safely
The complete integration requires a trusted server environment. A frontend-only implementation cannot safely sign the JWT.
If the repository contains only frontend code:
- do not sign the JWT in the browser;
- do not put the FeedLog SSO secret in public or client-side configuration;
- identify the link and frontend changes that will be needed;
- ask for the backend repository or an existing authenticated FeedLog redirect endpoint;
- report the integration as incomplete until the server-side redirect is connected.
If the repository contains only backend code:
- implement the authenticated/anonymous redirect and JWT signing;
- add the relevant tests;
- ask where the customer-facing frontend navigation is located;
- report that the user-facing link is still pending.
If both sides are present, complete both without asking for information the code already provides.
If the product has no authentication system, implement a direct FeedLog link instead of creating a new login system. Report that SSO cannot add identity until the product has a trusted server-side user session.
## Add the product link and redirect
Prefer one application-owned server route, using the project's existing route naming conventions. The product's user-facing FeedLog link should point to this route rather than embedding a JWT in rendered HTML.
When the route is requested:
1. Resolve and validate the requested FeedLog destination.
2. Read the current user from the trusted server-side session.
3. If a user is signed in, sign a new JWT and redirect to the FeedLog SSO endpoint.
4. If the authentication system confirms there is no signed-in user, redirect directly to the FeedLog destination without `jwt` or other identity parameters.
5. If reading the session fails unexpectedly, use the project's normal operational-error handling. Do not silently classify the failure as a signed-out state.
Generate the JWT when the link is followed, not during a long-lived page build or static render. This keeps the token short-lived and allows the route to choose the signed-in or anonymous branch at request time.
Find and update an existing Feedback or Feature requests link when one is clearly intended for FeedLog. Otherwise add one appropriate user-facing link by following the repository's information architecture and reusable navigation components. Keep desktop, mobile, and localized variants consistent where applicable.
If multiple link locations are equally plausible and the choice cannot be inferred, ask me one focused placement question. Do not add the link everywhere.
## Preserve the destination
Support a destination such as `/`, `/b/feature-requests`, or another path on the configured FeedLog host when the product needs deep links.
The signed-in and signed-out branches must land on the same FeedLog destination:
- signed in: redirect to `FEEDLOG_BASE_URL/api/sso/jwt?jwt=...&return_to=...`;
- signed out: redirect directly to `FEEDLOG_BASE_URL/...` for that destination.
Treat all redirect input as untrusted. Allow only destinations on the configured FeedLog origin. Reject or replace external, protocol-relative, malformed, or otherwise unsafe values. Do not create an open redirect.
Use URL-building APIs rather than string concatenation so the JWT and destination are encoded correctly.
## Sign the FeedLog JWT
Sign with HS256 on the server.
Supported claims:
- `email`: required; use the current authenticated user's valid email address;
- `exp`: required; Unix timestamp in seconds;
- `name`: optional;
- `picture`: optional; absolute avatar URL.
Use a one-hour lifetime by default. The expiration must not be more than 24 hours in the future. FeedLog allows approximately 60 seconds of clock tolerance.
For example, the payload should be equivalent to:
```ts
{
email: user.email,
name: user.name,
picture: user.avatarUrl,
exp: Math.floor(Date.now() / 1000) + 60 * 60,
}
```
Omit optional claims when the application does not have reliable values. Do not invent an email address when the current user has none. Handle that case safely according to project conventions and report the limitation. Do not trust email, name, or picture values supplied directly by the browser.
Reuse a suitable JWT library already present in the server project when possible. Otherwise add a maintained library compatible with the project's runtime. Do not implement cryptography manually.
Never log the JWT, SSO secret, session cookie, or other credentials. Avoid placing the signed JWT in analytics events or application logs. The JWT will appear only in the short-lived redirect URL sent to FeedLog.
## Configure the FeedLog URL and secret
The FeedLog SSO secret is created in:
FeedLog Dashboard -> Developer -> Single Sign-On -> New Secret
Use the secret exactly as the UTF-8 string shown by FeedLog. Do not hex-decode or Base64-decode it before signing.
First check whether suitable server-side variables already exist, without printing their values. Follow the project's naming convention. If no convention exists, use:
```env
FEEDLOG_BASE_URL=
FEEDLOG_SSO_SECRET=
```
The base URL may be exposed to the browser if the project needs it. `FEEDLOG_SSO_SECRET` must remain server-only and must not use a public prefix such as `VITE_`, `NEXT_PUBLIC_`, `NUXT_PUBLIC_`, or `PUBLIC_`.
If the FeedLog base URL cannot be discovered from current configuration, ask me for it. Do not guess it.
If the secret is not configured:
- add the server-side environment-variable declaration and an empty placeholder to the appropriate example environment file;
- do not generate a replacement secret;
- do not ask me to paste the real secret into chat;
- tell me how to create it in FeedLog and place it in the project's local secret store and deployment platform;
- ask me only to confirm when it has been configured.
You may complete code changes, static checks, and tests with a safe test-only secret, but do not claim that the live SSO flow was verified until the real deployment secret is configured. Never put a real secret in a fixture, snapshot, command output, or test log.
## Error handling
Handle at least these cases using the project's existing error conventions:
- the user is confirmed to be signed out;
- session lookup fails unexpectedly;
- the signed-in user has no valid email;
- the FeedLog base URL is missing or invalid;
- the FeedLog SSO secret is missing;
- JWT signing fails;
- the destination is unsafe or malformed.
The confirmed signed-out case is not an error: redirect the visitor directly to FeedLog. Other failures must not expose credentials or be silently treated as anonymous access.
## Verify the integration
Run the applicable repository checks, including lint, typecheck, tests, and production build. Do not fix unrelated pre-existing failures unless they block this integration; identify them separately.
Add focused tests where the project has an established test setup. Verify as many of these behaviors as the environment allows:
1. A signed-in request produces an HS256 JWT with the correct `email` and `exp`.
2. The JWT expires no more than 24 hours in the future.
3. Identity claims come from the trusted server session, not browser input.
4. A signed-in request redirects through FeedLog `/api/sso/jwt` with the intended `return_to`.
5. A confirmed signed-out request redirects directly to the same FeedLog destination without a JWT.
6. A session lookup failure is not misclassified as a signed-out request.
7. External or protocol-relative destinations cannot create an open redirect.
8. The SSO secret is absent from client code and the production client bundle.
9. The user-facing link works in desktop, mobile, and localized navigation where applicable.
10. The application builds and loads successfully.
11. When browser testing and a configured FeedLog instance are available, signed-in and signed-out navigation both reach the intended FeedLog page, with identity present only for the signed-in user.
Use the repository's approved browser-testing workflow when one exists. If browser verification is not possible, provide exact manual verification steps for both branches.
## Definition of done
Report the integration as complete only when:
- the product contains an appropriate user-facing FeedLog link;
- the server redirect distinguishes signed-in, signed-out, and session-failure states;
- signed-in users are handed off with a valid JWT;
- signed-out users reach FeedLog without being forced to sign in;
- redirect targets are restricted to the configured FeedLog origin;
- the secret remains server-only;
- the relevant automated checks pass;
- live verification is complete, or any external configuration that prevents it is clearly identified.
## Final report
At the end, report concisely:
1. the files changed;
2. where the user-facing FeedLog link appears;
3. where the application-owned redirect route lives;
4. how the current user is read and how a confirmed sign-out is represented;
5. how the FeedLog destination is validated;
6. the environment-variable names used, without their values;
7. the checks and tests run and their results;
8. the remaining FeedLog Dashboard or deployment steps;
9. anything incomplete or not verified.
Do not finish with only sample code or recommendations. Make the changes in the repository.如果项目缺少必要信息，Agent 可能会询问 FeedLog 地址，或者询问前端、后端代码的位置。你还需要有权限在 FeedLog 控制台中创建 SSO 密钥。