mirror of
https://github.com/agentrhq/authsome.git
synced 2026-09-19 01:34:19 +08:00
71b89fd036
The skill rewrite (PR #284) and README update standardized on "authsome <command>" (assumes "uv tool install authsome") and on agent-driven login flows. The docs site still spoke "uvx authsome" everywhere and didn't surface the auth-error decision tree the skill teaches. This brings the docs in line. Four kinds of change in one PR. 1. CLI prefix sweep ("uvx authsome" to "authsome"). Mechanical find/replace across docs/site/ excluding installation.mdx. 812 occurrences updated. installation.mdx keeps the literal "uvx" references because they explain the one-off run path. 2. installation.mdx rewrite. - "uv (recommended)" tab leads, with "uv tool install authsome". - pip second. - uvx demoted to "one-off, no install" with @latest pattern shown. - From source unchanged. - A Note at the top declares: every command in the docs is the installed form; uvx users prefix with "uvx authsome@latest". - All subsequent code blocks updated to bare "authsome". 3. New troubleshooting/auth-errors.mdx page. Captures the decision tree the skill teaches: 401 -> revoke + re-login; 403 -> "authsome login --scopes" (not re-registering); wrong client creds -> "authsome remove" then re-login. Registered in docs.json under Troubleshooting. 4. quickstart.mdx pivoted to two paths + help reflex. Path 1: agent-driven. Install the skill, ask the agent to do a task that needs an external service. The agent runs login itself. Path 2: CLI-driven. The existing manual walkthrough, preserved. Adds a Tip about reading "authsome --help" and "authsome <cmd> --help" before guessing flags. 5. Agent-mode note on the four skill-based integration pages. claude-code, codex, cursor, opencode each get a one-paragraph Note clarifying that the agent runs login, opens the browser on the user's machine for OAuth, and that users should not paste keys into prompts or pre-run login commands. The four SDK-style integration pages (langchain, llamaindex, openai-agents-sdk, anthropic-sdk) are unchanged because their pattern is developer-driven, not agent-driven. Verified clean: no "uvx authsome" outside installation.mdx, docs.json valid, no em-dashes introduced.
80 lines
2.9 KiB
Plaintext
80 lines
2.9 KiB
Plaintext
---
|
|
title: "LangChain"
|
|
sidebarTitle: "LangChain"
|
|
description: "Use authsome with LangChain. Pull fresh tokens at agent construction or run the whole chain under the proxy."
|
|
icon: "link"
|
|
keywords: ["langchain authsome", "langchain credentials", "langchain oauth", "langchain api keys"]
|
|
---
|
|
|
|
[LangChain](https://www.langchain.com) reads provider credentials from environment variables or constructor arguments. The recommended setup: run the chain under authsome's proxy and let LangChain's SDKs read the placeholder env vars unchanged.
|
|
|
|
## Run the whole chain under the proxy
|
|
|
|
```bash
|
|
authsome login openai
|
|
authsome login github
|
|
authsome run -- python my_chain.py
|
|
```
|
|
|
|
LangChain SDKs read placeholder env vars (`OPENAI_API_KEY=authsome-proxy-managed`) and initialize. The proxy substitutes the real key for outbound HTTPS to `api.openai.com`, `api.github.com`, and other matched hosts. No code changes to your chain.
|
|
|
|
## Tools that call out to providers
|
|
|
|
Many LangChain tools (`GitHubToolkit`, `SerpAPIWrapper`, `BraveSearch`, etc.) read their secret from an env var. With the proxy already wrapping the process, the existing wrappers just work:
|
|
|
|
```python
|
|
from langchain_community.utilities import SerpAPIWrapper
|
|
|
|
# reads SERPAPI_API_KEY from env, which is the proxy placeholder
|
|
search = SerpAPIWrapper()
|
|
```
|
|
|
|
For tools that authsome doesn't bundle, add a [custom provider](/guides/custom-providers) so the proxy can match by host.
|
|
|
|
## Embedding the library
|
|
|
|
If you're building a larger orchestrator around LangChain and need to pass tokens explicitly (different connection per call, or TLS-pinned SDKs that bypass the proxy), drop down to the library:
|
|
|
|
```python
|
|
from authsome.server.dependencies import create_auth_service
|
|
from langchain_openai import ChatOpenAI
|
|
from langchain_community.tools.github.tool import GitHubAction
|
|
|
|
auth = create_auth_service()
|
|
|
|
llm = ChatOpenAI(
|
|
api_key=auth.get_access_token("openai"),
|
|
model="gpt-4o-mini",
|
|
)
|
|
|
|
github = GitHubAction(
|
|
github_access_token=auth.get_access_token("github"),
|
|
)
|
|
```
|
|
|
|
Refresh is transparent. Construct the clients once per request rather than caching them across long-running processes if your tokens have short TTLs.
|
|
|
|
## Async clients
|
|
|
|
`AsyncChatOpenAI` and other async wrappers work identically. Authsome's auth layer is synchronous; if you do use the library, call `get_access_token` once at client construction and pass the value in.
|
|
|
|
## Multi-account workflows
|
|
|
|
```python
|
|
work = auth.get_access_token("github", connection="work")
|
|
personal = auth.get_access_token("github", connection="personal")
|
|
```
|
|
|
|
See [Multiple connections per provider](/guides/multiple-connections).
|
|
|
|
## What's next
|
|
|
|
<Columns cols={2}>
|
|
<Card title="Python library" icon="code" href="/reference/python-library">
|
|
The full library surface.
|
|
</Card>
|
|
<Card title="OpenAI integration" icon="key" href="/integrations/api-key/openai">
|
|
Set up the OpenAI key LangChain will use.
|
|
</Card>
|
|
</Columns>
|