Skip to content

Conversation

@Flix6x
Copy link
Contributor

@Flix6x Flix6x commented May 24, 2024

Closes #904.

Flix6x added 2 commits May 24, 2024 10:35
Signed-off-by: F.N. Claessen <[email protected]>
Signed-off-by: F.N. Claessen <[email protected]>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nhoening I need advice on where to move these new util functions, for example, to:

  • api/common/utils/args_parsing.py
  • auth/loaders.py
  • or elsewhere, maybe even becoming a new acl method on some class? I'm out of my league here.

I saw other ctx_loaders were pointing to various things, such as:

  • ctx_loader=lambda bdf: bdf.sensor
  • ctx_loader=GenericAsset
  • ctx_loader=AccountIdField.load_current
  • ctx_loader=AuditLog.account_table_acl
  • ctx_loader=AuditLog.user_table_acl

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These have nothing to do with auth directly, but are lookup functions that rely on our planning data structure. So I guess this location isn't bad, really.

I don't see why ctx_loader should be used, as no AuthContext is touched.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why ctx_loader should be used, as no AuthContext is touched.

I'm not sure what to do with this. Am I using ctx_loader incorrectly?

Flix6x added 3 commits May 24, 2024 13:15
Signed-off-by: F.N. Claessen <[email protected]>
Signed-off-by: F.N. Claessen <[email protected]>
Signed-off-by: F.N. Claessen <[email protected]>
@Flix6x Flix6x mentioned this pull request May 24, 2024
12 tasks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These have nothing to do with auth directly, but are lookup functions that rely on our planning data structure. So I guess this location isn't bad, really.

I don't see why ctx_loader should be used, as no AuthContext is touched.

Flix6x and others added 5 commits June 10, 2024 16:29
@Flix6x Flix6x added this to the 0.23.0 milestone Aug 19, 2024
Copy link
Contributor

@nhoening nhoening left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the improvements, this is good.
I disagree with one potential security problem in particular, like in the last review.

context_from_args = kwargs.get(ctx_arg_name)
# skip check in case (optional) argument was not passed
if context_from_args is None:
return None
Copy link
Contributor

@nhoening nhoening Sep 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I (still) believe this should be a LookupError. Above, you skip the auth check if this looking up of a context by argument name did not work out (which I also am in favor of not doing). This could quite easily happen by programmer mistake, and could easily be overlooked during testing.

ctx_arg_name is an optional attribute, but if it is given, we need to actually use it.

Copy link
Contributor Author

@Flix6x Flix6x Sep 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the major problem blocking my progress on this PR. How do you propose I deal with checking authorization on an optional argument (in this case coming from an optional API field)? Should I add a boolean argument to permission_required_for_context telling the argument is optional (i.e. skip if context is None) or required (i.e. raise if context is None)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not check that context_from_args has to be something if the developer gave information to look it up?

I.e. if ctx_arg_name is not None, then we expect that context_from_args is also not None, otherwise we got wrong parameterisation.

Simply put, if permission_required_for_context() has no context, we cannot say the permission is granted.

Why did you change the logic so that it could be granted? The field was optional before. Maybe it is because the flex context can contain no sensors to check? That is a case I can imagine, and maybe we could add a parameter to permission_required_for_context() that says pass_if_no_context_found or similar.

But the interpretation has to fit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was because flex_model and flex_context could be None, as they are optional parameters. In that case, the context is None, too, and we should pass the permissions check: i.e. the fields contain no sensor references, so there is nothing to check. I still don't really understand why we shouldn't grant permission on a None context, but by now I did find an alternative fix, by setting load defaults for the flex_context and flex_model. So now they are no longer None, but empty dicts instead.

context = [context]
for ctx in context:
if isinstance(ctx, tuple):
c = ctx[0] # c[0] is the context, c[1] is its origin
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's mention for ease of reading that the origin is just a string.


def load_context(
ctx_arg_pos, ctx_arg_name, ctx_loader, pass_ctx_to_loader, args, kwargs
) -> AuthModelMixin | None:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this return type still valid? It can be a list or tuples with origins, right?

context = context_from_args
if context is None:
raise LookupError(f"No context could be loaded from {context_from_args}.")
return context
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thought: We provide several means of looking up context(s). Should we maybe check here that all context(s) are actually a subclass of AuthModelMixin and throw a meaningful LookupError if they are not?

I just checked, and check_access does this check. So we can not do it here. But it could help debugging problems.

@permission_required_for_context(
"read",
ctx_arg_name="flex_model",
ctx_loader=flex_model_loader,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add a comment: "This extracts sensors from the flex model parameter - user needs read access to them"

@nhoening nhoening modified the milestones: 0.23.0, 0.24.0 Sep 18, 2024
@Flix6x Flix6x modified the milestones: 0.24.0, 0.25.0 Jan 7, 2025
@nhoening nhoening modified the milestones: 0.25.0, 0.26.0 Apr 1, 2025
@Flix6x Flix6x modified the milestones: 0.26.0, 0.27.0 Jun 2, 2025
@Flix6x Flix6x modified the milestones: 0.27.0, 0.28.0 Jul 17, 2025
@nhoening nhoening modified the milestones: 0.28.0, 0.29 Sep 9, 2025
@nhoening nhoening modified the milestones: 0.29.0, 0.30.0 Oct 15, 2025
…-permissions-of-entities-within-flex-model-or-flex-context
Signed-off-by: F.N. Claessen <[email protected]>
…so now permission_required_for_context still doesn't work with optional contexts

Signed-off-by: F.N. Claessen <[email protected]>
@read-the-docs-community
Copy link

read-the-docs-community bot commented Nov 29, 2025

Documentation build overview

📚 flexmeasures | 🛠️ Build #30501709 | 📁 Comparing 70e3615 against latest (208943a)


🔍 Preview build

Show files changed (7 files in total): 📝 7 modified | ➕ 0 added | ➖ 0 deleted
File Status
changelog.html 📝 modified
genindex.html 📝 modified
_autosummary/flexmeasures.api.common.responses.html 📝 modified
_autosummary/flexmeasures.auth.decorators.html 📝 modified
_autosummary/flexmeasures.data.models.planning.utils.html 📝 modified
api/change_log.html 📝 modified
api/v3_0.html 📝 modified

@nhoening nhoening modified the milestones: 0.30.0, 0.31.0 Dec 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Read permissions of entities within flex-model or flex-context

3 participants