mirror of
https://github.com/windmill-labs/windmill.git
synced 2026-09-21 16:02:36 +00:00
Diego ImbertandClaude Opus 5
34ed0c4230
A data table backed by the instance database resolved to exactly one Postgres connection, `custom_instance_user`, for everyone who could reach it at all. There was no way to say this job reads, that one writes, this one never sees the salaries table. A data table role is now a real Postgres login on the cluster, defined once for the instance by a superadmin and named exactly as they named it. A script that declares `-- role analytics` connects as `analytics`, and Postgres decides what it may touch — grants are ordinary SQL. Windmill answers only "may this caller ask for this role", from the tenant lists on the data table entry: `u/alice`, `g/analysts`, `f/finance` or `*`. A data table with no `permissions` block behaves exactly as before. Everything that opens a connection on someone's behalf goes through one chokepoint, `get_datatable_resource_from_db`, which takes the identity explicitly and fails closed when there is none. The role logs in as itself — never `SET ROLE`, which a script could `RESET ROLE` its way out of. A fork's data table entry becomes a pointer at the workspace that governs it rather than a copy of it. The settings clone used to hand a fork a byte-identical entry naming the parent's database, which a fork admin could edit to grant themselves `admin` there; a pointer has nothing local to edit, and its tenants are evaluated as a member of the governing workspace, by email. `permissions` is stripped from the workspace export and ignored on import: tenants name principals of one workspace, and a settings push is not where an access decision should be made. Operations that see the whole database whatever the roles grant stay with the governing workspace's admins: editing the roles, a migration that declares none, and opening a replication stream for a Postgres trigger or capture. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012ti5HyeTikPMYyW8YSdiHR
wmill
The core client for the Windmill platform.
Usage
Basic Usage
The wmill package has several methods at the top-level for the most frequent operations you will need.
The following are some common examples:
import time
import wmill
def main():
# Get the value of a variable
wmill.get_variable("u/user/variable_path")
# Run a script synchronously and get the result
wmill.run_script("f/pathto/script", args={"arg1": "value1"})
# Get the value of a resource
wmill.get_resource("u/user/resource_path")
# Set the script's state
wmill.set_state({"ts": time.time()})
# Get the script's state
wmill.get_state()
Advanced Usage
The wmill package also exposes the Windmill class, which is the core client for the Windmill platform.
import time
from wmill import Windmill
def main():
client = Windmill(
# token=... <- this is optional. otherwise the client will look for the WM_TOKEN env var
)
# Get the current version of the client
client.version
# Get the current user
client.user
# Convenience get and post methods exist for https://app.windmill.dev/openapi.html#/
# these are thin wrappers around the httpx library's get and post methods
# list worker groups
client.get("/configs/list_worker_groups")
# create a group
client.post(
f"/w/{client.workspace}/groups/create",
json={
"name": "my-group",
"summary": "my group summary",
}
)
# Get and set the state of the script
now = time.time()
client.state = {"ts": now}
assert client.state == {"ts": now}
# Run a job asynchronously
job_id = client.run_script_async(path="path/to/script")
# Get its status
client.get_job_status(job_id)
# Get its result
client.get_result(job_id)