Add model version search filtering based on user permissions#20964
Add model version search filtering based on user permissions#20964TomeHirata merged 3 commits intomlflow:masterfrom
Conversation
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
🛠 DevTools 🛠
Install mlflow from this PRFor Databricks, use the following command: |
| response_message = SearchModelVersions.Response() | ||
| parse_dict(resp.json, response_message) | ||
|
|
||
| # fetch permissions |
There was a problem hiding this comment.
I intentionally didn't add "re-fetch to fill max results" logic as it increases the complexity and lower the performance. So I think we can start with just filtering and then add the re-fetch if requested.
There was a problem hiding this comment.
Pull request overview
Adds authorization-aware filtering to model version search results so users only see model versions belonging to registered models they can read, aligning model version search with existing permission-based filtering in the auth layer.
Changes:
- Add after-request filtering for
SearchModelVersionsresponses based on registered model read permissions. - Add GraphQL middleware support for
mlflowSearchModelVersionswith result filtering. - Add a unit/integration test covering basic visibility differences between owner vs. a user with READ on a subset of models.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
mlflow/server/auth/__init__.py |
Adds REST after-request filtering for SearchModelVersions and GraphQL result filtering for mlflowSearchModelVersions. |
tests/server/auth/test_auth.py |
Adds a test validating search_model_versions visibility under different user permissions. |
|
Documentation preview for 5a1a9e6 is available at: Changed Pages (1)
More info
|
| return None | ||
|
|
||
| return next(root, info, **args) | ||
| result = next(root, info, **args) |
There was a problem hiding this comment.
interesting, so the graphQL authorization is handled separately from the normal REST auth? out of the scope of this PR but it seems like we should somehow try to merge them as we need to remember to update 2 places now 🤔
There was a problem hiding this comment.
graphQL authorization is handled separately from the normal REST auth?
Yes, this is the current design; agree there should be a way to consolidate them. But for now we don't have many gql resources.
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
…20964) Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
Signed-off-by: Tomu Hirata <tomu.hirata@gmail.com>
Related Issues/PRs
https://huntr.com/bounties/d632f783-b2c7-4a3b-af5e-1d693e841c08
What changes are proposed in this pull request?
As titled
How is this PR tested?
Does this PR require documentation update?
Does this PR require updating the MLflow Skills repository?
Release Notes
Is this a user-facing change?
What component(s), interfaces, languages, and integrations does this PR affect?
Components
area/tracking: Tracking Service, tracking client APIs, autologgingarea/models: MLmodel format, model serialization/deserialization, flavorsarea/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registryarea/scoring: MLflow Model server, model deployment tools, Spark UDFsarea/evaluation: MLflow model evaluation features, evaluation metrics, and evaluation workflowsarea/gateway: MLflow AI Gateway client APIs, server, and third-party integrationsarea/prompts: MLflow prompt engineering features, prompt templates, and prompt managementarea/tracing: MLflow Tracing features, tracing APIs, and LLM tracing functionalityarea/projects: MLproject format, project running backendsarea/uiux: Front-end, user experience, plotting, JavaScript, JavaScript dev serverarea/build: Build and test infrastructure for MLflowarea/docs: MLflow documentation pagesHow should the PR be classified in the release notes? Choose one:
rn/none- No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" sectionrn/breaking-change- The PR will be mentioned in the "Breaking Changes" sectionrn/feature- A new user-facing feature worth mentioning in the release notesrn/bug-fix- A user-facing bug fix worth mentioning in the release notesrn/documentation- A user-facing documentation change worth mentioning in the release notesShould this PR be included in the next patch release?
Yesshould be selected for bug fixes, documentation updates, and other small changes.Noshould be selected for new features and larger changes. If you're unsure about the release classification of this PR, leave this unchecked to let the maintainers decide.What is a minor/patch release?
Bug fixes, doc updates and new features usually go into minor releases.
Bug fixes and doc updates usually go into patch releases.