mirror of
https://github.com/langflow-ai/langflow.git
synced 2026-07-24 00:03:32 +08:00
aafce557aa
* feat(authz): add roles, role-assignments, teams, and me/permissions APIs
Completes the OSS admin surface for RBAC: full CRUD on authz_role,
authz_role_assignment, authz_team, and authz_team_member tables, plus a
per-user effective-permissions endpoint backing the frontend permission gate.
Plugin (enterprise Casbin) is invalidated on every write so the next enforce
sees the change.
New endpoints:
* GET/POST/PATCH/DELETE /api/v1/authz/roles -- custom-role CRUD with parent
cycle detection, system-role protection, and FK-aware delete (409 when
assignments still reference the role).
* GET/POST/DELETE /api/v1/authz/role-assignments -- list filterable by
user/role/domain; superuser-only for write, self-read allowed.
* GET/POST/PATCH/DELETE /api/v1/authz/teams + GET/POST/DELETE
/api/v1/authz/teams/{id}/members -- backs the share-with-team flow and
the team admin UI.
* POST /api/v1/authz/me/permissions -- returns per-resource allowed actions
for the current user (capped at 500 ids), backs the FE permission gate.
Base service additions (lfx.services.authorization.base):
* list_visible_resource_ids -- plugin SQL prefilter for list endpoints; OSS
returns None ("no prefilter, fall through to filter_visible_resources").
* get_effective_permissions -- default impl uses batch_enforce so plugins
inherit it for free; Casbin plugin can override for a tighter query.
* fix(authz): make build_flow share-aware so shared flows can be run by non-owners
The build_flow handler was loading flows with an owner-OR-public SQL filter,
short-circuiting the ensure_flow_permission(EXECUTE) check on private flows
shared with the current user. The existing in-code comment flagged this as a
Phase 3 prerequisite for cross-user build support.
Switch to the share-aware load helper (_read_flow / authorized_or_owner_scoped):
* When the registered authorization plugin signals SUPPORTS_CROSS_USER_FETCH
(enterprise Casbin), the row loads by id alone and the plugin decides via
enforce(). OSS pass-through keeps the historical owner-only behavior.
* PUBLIC flows are still buildable by any authenticated user in both modes
(preserved via the explicit access_type=PUBLIC fallback).
* Plugin deny is translated to 404 (not 403) via deny_to_404 so the response
is indistinguishable from "flow does not exist" and the caller cannot
enumerate UUIDs by probing for 403 vs 404.
* test(authz): cover new admin routes and share-aware build_flow
Pins the security floor and validation behavior added in the prior commits so
they don't silently regress. Uses the existing fake async session + stub authz
service pattern from test_authz_share_routes.py.
test_authz_admin_routes.py (17 tests):
* /authz/roles -- superuser gate on create, persist + invalidate_all, 409 on
name conflict, system-role protection on update + delete, self-parent and
parent-cycle rejection, 409 when deleting a role with active assignments.
* /authz/role-assignments -- non-superuser blocked from listing other users'
assignments; self-list allowed; 404 when user_id is unknown; create
invokes invalidate_user(target).
* /authz/teams -- superuser gate on create, add_member invokes
invalidate_user(target), duplicate add returns 409.
* /authz/me/permissions -- correct per-resource shape, 400 when over 500
ids, empty request returns empty.
test_chat_build_flow_authz.py (5 tests):
* Owner happy path preserved.
* Plugin 403 deny converted to 404 (UUID privacy).
* Unknown flow + no PUBLIC fallback -> 404.
* Share-aware load miss + PUBLIC fallback hits -> success.
* Non-403 errors (e.g. 500) pass through with status preserved.
Total: 22 new tests, all passing locally.
* fix(authz): normalize, dedupe, and cap the actions list on /authz/me/permissions
The resource_ids cap (500) bounded one side of the cartesian product, but the
actions list was unbounded. A client could submit actions=["read"] * 100000
and trigger a 50M-entry batch_enforce, plus the same action in different
casings ("READ", "read") would have been treated as distinct entries.
Add a field_validator on EffectivePermissionsRequest.actions that:
* strips whitespace and lowercases each entry
* de-duplicates while preserving order
* caps the result at 10 unique actions (headroom over the 6 known actions:
read, write, execute, delete, create, manage)
* returns None when the normalized list is empty so the handler still falls
back to _DEFAULT_ACTIONS
Over-cap requests raise ValidationError (HTTP 422 at the request boundary),
which matches Pydantic conventions for input shape problems and differs from
the resource_ids cap (HTTP 400 in the handler) by design -- bound-violation
on list size is structurally a validation error, not application logic.
6 new tests: normalization+dedupe, empty-collapses-to-None, over-cap rejection,
50-entry dedupe stays under cap, None stays None, handler sees normalized list.
* fix(authz): default /authz/role-assignments list to caller's own assignments
The gate `if user_id is None or user_id != current_user.id` required superuser
whenever user_id was omitted, so any non-superuser calling
GET /authz/role-assignments with no query params got 403 even though the
docstring promised "Users may query their own assignments".
Resolve user_id to current_user.id when omitted, then only gate superuser when
the resolved id differs from the caller. The query is now always filtered by
the resolved user_id, so admins doing cross-user lookups make one call per
user instead of relying on an unscoped see-all.
Adds test_list_assignments_no_user_id_defaults_to_self pinning the new
behavior. The other two assignment-list tests (self with explicit user_id,
non-superuser blocked from another user) remain unchanged and still pass.
* fix(authz): use model_fields_set so PATCH /authz/roles can clear nullable fields
The "if payload.<field> is not None" guards made it impossible to clear
description or parent_role_id via PATCH -- an explicit "description": null
in the body was indistinguishable from omitting the field, leaving the old
value in place.
Switch to presence checks via payload.model_fields_set:
* description: nullable on the DB side, so an explicit null clears the field.
* parent_role_id: nullable + SET NULL on cascade; null removes the parent.
* name: NOT NULL + unique on the DB side. The presence check applies, but
an explicit null is rejected at the boundary with HTTP 400 so the caller
sees a clear error instead of an opaque 409 "Name conflict" from the
IntegrityError catch block below.
* permissions: nullable=False (default_factory=list) on the DB side. An
empty list is the natural "clear"; null is rejected with HTTP 400.
6 new tests: clear description via null, clear parent via null, omitted
fields untouched, reject null name, clear permissions via empty list,
reject null permissions.
Adds _make_role_row helper so SimpleNamespace fakes carry every field
that RoleRead.model_validate expects (workspace_id, created_at, created_by).
* fix(authz): use model_fields_set so PATCH /authz/teams can clear description
The "if payload.description is not None" guard made the description field
unclearable via PATCH -- an explicit "description": null was indistinguishable
from omitting the field, leaving the old value in place.
Switch to a presence check via payload.model_fields_set so null clears the
field, while omission still leaves the row alone. The DB column is nullable,
so None is a legitimate value here.
Scope intentionally narrow: team_name and adom_name are NOT NULL on the DB
side (null would crash on commit) and is_active is bool (null doesn't model
any state), so they keep the existing is-not-None guards.
Adds 2 tests: clear via explicit null, omission leaves value untouched.
Adds _make_team_row helper for parity with _make_role_row.
* fix(authz): validate batch_enforce result length in get_effective_permissions
The default get_effective_permissions impl built `requests` as a cartesian
product of resource_ids x actions, called batch_enforce, then sliced the
flat result back into per-resource action lists. If a plugin's batch_enforce
returned the wrong number of results -- contract violation -- the slicing
silently produced incorrect mappings:
* too-short flat: later resources got `[]` (out-of-bounds slice returns empty
in Python) instead of their real permissions
* too-long flat: tail entries silently dropped
The inner `zip(..., strict=True)` only caught the per-slice mismatch when a
slice happened to be too short, not the global length mismatch.
Validate `len(flat) == len(requests)` immediately after the call and raise
ValueError with expected/actual counts so plugin authors find the contract
break at the first wrong call, not via mysteriously-empty permission lists.
Adds two lfx tests:
* default impl returns full action list per resource (no enforcement)
* mocked batch_enforce returning a wrong-sized list raises ValueError
* fix: remove EE references
* fix: harden authz admin APIs based on PR review
- Pin permission slug format to canonical <resource>:<action> and validate
RoleCreate/RoleUpdate at the API boundary so bad slugs cannot land in
authz_role.permissions and silently fail policy sync.
- Tighten RoleAssignmentCreate: domain_type is a Literal and a model
validator enforces domain_id consistency (required for org/workspace/
project, forbidden for global).
- Restore _resolve_casbin_domain re-export for plugin backward compat.
- Audit-log policy-changing admin writes (role CRUD, role-assignment
create/delete, team CRUD, team membership add/remove) so privilege
grants are visible alongside enforcement decisions.
- Invalidate authorization cache when a team's adom_name or is_active
changes; pure display edits still skip the flush.
* review feedback
* [autofix.ci] apply automated fixes
* fix(authz): harden build_flow and expose authz_enabled on config
Block non-owners from overriding flow graph data on shared builds,
revert unrelated component_index.json churn, and surface
LANGFLOW_AUTHZ_ENABLED on public and authenticated config responses
for EE UI gating.
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Co-authored-by: himavarshagoutham <himavarshajan17@gmail.com>
Co-authored-by: Himavarsha <40851462+HimavarshaVS@users.noreply.github.com>
Langflow is a powerful platform for building and deploying AI-powered agents and workflows. It provides developers with both a visual authoring experience and built-in API and MCP servers that turn every workflow into a tool that can be integrated into applications built on any framework or stack. Langflow comes with batteries included and supports all major LLMs, vector databases and a growing library of AI tools.
✨ Highlight features
- Visual builder interface to quickly get started and iterate.
- Source code access lets you customize any component using Python.
- Interactive playground to immediately test and refine your flows with step-by-step control.
- Multi-agent orchestration with conversation management and retrieval.
- Deploy as an API or export as JSON for Python apps.
- Deploy as an MCP server and turn your flows into tools for MCP clients.
- Observability with LangSmith, LangFuse and other integrations.
- Enterprise-ready security and scalability.
🖥️ Langflow Desktop
Langflow Desktop is the easiest way to get started with Langflow. All dependencies are included, so you don't need to manage Python environments or install packages manually. Available for Windows and macOS.
⚡️ Quickstart
Install locally (recommended)
Requires Python 3.10–3.13 and uv (recommended package manager).
Install
From a fresh directory, run:
uv pip install langflow -U
The latest Langflow package is installed. For more information, see Install and run the Langflow OSS Python package.
Run
To start Langflow, run:
uv run langflow run
Langflow starts at http://127.0.0.1:7860.
That's it! You're ready to build with Langflow! 🎉
📦 Other install options
Run from source
If you've cloned this repository and want to contribute, run this command from the repository root:
make run_cli
For more information, see DEVELOPMENT.md.
Docker
Start a Langflow container with default settings:
docker run -p 7860:7860 langflowai/langflow:latest
Langflow is available at http://localhost:7860/. For configuration options, see the Docker deployment guide.
🛡️ Security
For security information, see our Security Policy.
🚀 Deployment
Langflow is completely open source and you can deploy it to all major deployment clouds. To learn how to deploy Langflow, see our Langflow deployment guides.
⭐ Stay up-to-date
Star Langflow on GitHub to be instantly notified of new releases.
👋 Contribute
We welcome contributions from developers of all levels. If you'd like to contribute, please check our contributing guidelines and help make Langflow more accessible.