Skip to content

fix: [Resource Authorization] When a role is assigned "Public Access Link" permissions but has "Access Settings" permissions revoked, attempting to toggle the Web access switch results in a "no permission" error. - #7756

Merged
shaohuzhang1 merged 1 commit into
v3from
pr@v3@fix_access_token
Nov 9, 2026

Conversation

@shaohuzhang1

Copy link
Copy Markdown
Contributor

fix: [Resource Authorization] When a role is assigned "Public Access Link" permissions but has "Access Settings" permissions revoked, attempting to toggle the Web access switch results in a "no permission" error.

…Link" permissions but has "Access Settings" permissions revoked, attempting to toggle the Web access switch results in a "no permission" error.
@shaohuzhang1
shaohuzhang1 merged commit 2545f23 into v3 Nov 9, 2026
3 of 4 checks passed
return result.success(
AccessTokenSerializer(data={'workspace_id': workspace_id, 'application_id': application_id}).one())
AccessTokenSerializer(data={"workspace_id": workspace_id, "application_id": application_id}).one()
)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

The diff is mostly Black-style formatting. The only behavior-changing line I see is the PUT permission constant:

- PermissionConstants.APPLICATION_OVERVIEW_ACCESS.get_workspace_application_permission()
+ PermissionConstants.APPLICATION_OVERVIEW_PUBLIC.get_workspace_application_permission()

Main concern

  • Verify the permission change is intentional. This changes who can modify application access-token settings. For an endpoint described as “Modify application access restriction information”, APPLICATION_OVERVIEW_ACCESS seems more semantically correct than APPLICATION_OVERVIEW_PUBLIC. If this was accidental, revert it. If intentional, add/update permission tests and confirm it does not broaden access unexpectedly.
  • Also check consistency: GET uses APPLICATION_READ, while PUT now uses APPLICATION_OVERVIEW_PUBLIC. Make sure this matches the intended permission model.

Potential issues

  1. Direct QuerySet(model=Application) is unusual and risky
application_model = QuerySet(model=Application).filter(id=application_id).first()

This bypasses the model manager (Application.objects) and any custom manager/default filtering. Prefer:

def get_application_operation_object(application_id):
    application_model = Application.objects.filter(pk=application_id).values("name").first()
    return application_model or {}

This also avoids fetching all fields.

  1. Serializer validation is not visible
AccessTokenSerializer(data={...}).edit(request.data)

and

AccessTokenSerializer(data={...}).one()

If edit() / one() do not call is_valid(raise_exception=True) internally, validation may be skipped. Verify this; otherwise add explicit validation.

  1. Redundant parentheses in the lambda
get_operation_object=lambda r, k: get_application_operation_object((k.get("application_id")))

Simplify to:

get_operation_object=lambda r, k: get_application_operation_object(k.get("application_id"))
  1. Translated operation_id may be problematic
operation_id=_("Modify application access restriction information")

operation_id should be stable and unique for API schema/code generation. Translating it can produce locale-dependent or duplicate operation IDs. Prefer a fixed non-translated string. This is pre-existing, but worth flagging.

  1. Formatting changes are fine, but unrelated

Most quote changes, blank lines, and line wrapping are harmless. If the project uses Black, keep them. If not, avoid unrelated formatting churn in a functional change.

Summary

  • Must check: PUT permission constant changed from APPLICATION_OVERVIEW_ACCESS to APPLICATION_OVERVIEW_PUBLIC.
  • Recommended: use Application.objects.filter(...).values("name").first() instead of QuerySet(model=Application).
  • Recommended: remove redundant parentheses in get_operation_object.
  • Verify: serializer validation inside .edit() / .one().
  • Verify: translated operation_id does not break schema generation.

@shaohuzhang1
shaohuzhang1 deleted the pr@v3@fix_access_token branch November 9, 2026 07:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant