Skip to content

Conversation

guillett
Copy link
Contributor

@guillett guillett commented May 5, 2025

Context

As a document owner I want to be able to check check how the document appears to other people.
ACL views is very useful for than.
Unfortunately, in a custom widget grist.docApi.getAccessToken does not return a token for the impersonated user but for myself.

With that PR, I can get an access token for the "good" user.

Broader context

Split #1512 into two PRs.

Two issues coexist :

  1. ACL rules are not applied in custom widgets (via access tokens)
  2. Access to attachments is bogus in widgets (via access tokens)

But:

  1. is pretty straightfoward.
  2. has security implications.

This PR is to solve 1. and leaves 2. to the original PR.

Proposed solution

Apply _granularAccess

Has this been tested?

  • 👍 yes, I added tests to the test suite
  • 💭 no, because this PR is a draft and still needs work
  • 🙅 no, because this is not relevant here 😬
  • 🙋 no, because I need help

@paulfitz
Copy link
Member

paulfitz commented May 5, 2025

ACL rules are not applied in custom widgets (via access tokens)
...
Apply _granularAccess

@guillett are you seeing a case where granular access rules for a document are not applied when that document is accessed using access tokens? That would be very serious. I tried replicating but have not succeeded yet.

@guillett
Copy link
Contributor Author

guillett commented May 5, 2025

@paulfitz sorry, I should I provided more context. I updated the title and initial comment. Here is the addition

As a document owner I want to be able to check check how the document appears to other people.
ACL views is very useful for than.
Unfortunately, in a custom widget grist.docApi.getAccessToken does not return a token for the impersonated user but for myself.

@guillett guillett changed the title Fix ACL rule application in widgets Fix accessToken generation in custom widgets May 5, 2025
@guillett guillett changed the title Fix accessToken generation in custom widgets Apply ACL in accessToken generation in custom widgets May 5, 2025
@guillett
Copy link
Contributor Author

guillett commented May 5, 2025

The onRecords function and ${tokenInfo.baseUrl}/tables/${tableId}/records?auth=${tokenInfo.token} does not return the same values.

demo (but not really interesting because I didn't add your emails)
basic custom widget that mimicks inspect/onRecords.

@guillett
Copy link
Contributor Author

guillett commented May 5, 2025

To illustrate the issues on both #1594 and #1512

As an owner ([email protected] with userId = 27671)

Capture d’écran du 2025-05-05 18-04-47

Using ACL with an editor user ([email protected])

  • Data incorrectly censored for similar reason.
  • userId in token is incorrect because its [email protected] one.

Capture d’écran du 2025-05-05 18-04-50

As anon user

  • Data is censored, that's ok
  • UserId is ok
    Capture d’écran du 2025-05-05 18-04-53

@paulfitz
Copy link
Member

paulfitz commented May 5, 2025

@paulfitz sorry, I should I provided more context. I updated the title and initial comment. Here is the addition

As a document owner I want to be able to check check how the document appears to other people.
ACL views is very useful for than.
Unfortunately, in a custom widget grist.docApi.getAccessToken does not return a token for the impersonated user but for myself.

Ok I think I understand now, you are talking about the View as another user feature, correct? Yes, it would be reasonable to extent that feature to cover getAccessToken calls from custom widgets.

"Apply ACL" and "ACL views" could mean many things, it would be worth rephrasing.

Then I think I see you reporting more limitations of the current implementation of getAccessToken, which is reasonable, it was added for one specific purpose and it could definitely do with some love to generalize it.

@guillett guillett changed the title Apply ACL in accessToken generation in custom widgets Fix accessToken generated in custom widgets using the "view as aonther user" feature May 5, 2025
@fflorent fflorent moved this to Needs feedback in French administration Board May 7, 2025
@paulfitz paulfitz changed the title Fix accessToken generated in custom widgets using the "view as aonther user" feature Fix accessToken generated in custom widgets using the "view as another user" feature May 8, 2025
Copy link
Member

@paulfitz paulfitz left a comment

Choose a reason for hiding this comment

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

Thanks @guillett. Looks plausible. Can you add a test or tests for this? test/server/lib/AccessTokens.ts could be a good place. The "view as another user" feature interacts with the back end by adding a [email protected] query parameter.

This PR touches on security, so will need two reviewers. Once it has tests I'll recruit another reviewer.

@guillett
Copy link
Contributor Author

hi @paulfitz thanks for your feedback on adding a test. I chose to add a test in test/server/lib/GranularAccess.ts rather than in test/server/lib/AccessTokens.ts because it already had reopenClients that is useful in the context.

public async getAccessToken(docSession: OptDocSession, options: AccessTokenOptions): Promise<AccessTokenResult> {
const tokens = this._server.getAccessTokens();
const userId = docSession.userId;
const user = await this._granularAccess.getUser(docSession);
Copy link
Member

Choose a reason for hiding this comment

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

This seems a reasonable improvement.

}
const userId = tokenObj.userId;
const user = await dbManager.getUser(userId);
setRequestUser(mreq, dbManager, user!);
Copy link
Member

Choose a reason for hiding this comment

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

This looks like an unrelated change? And one that needs some testing to demonstrate that it hasn't introduced a weakness, as discussed in other PRs.

Copy link
Member

Choose a reason for hiding this comment

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

If this is about uploading attachments, it would be good to link to an issue specifically about that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh sorry, I requested a new review on the wrong PR.

I stacked my PRs so, indeed it is a code change related to #1614.

This PR (#1594) can be reviewed after #1614 is merged to limit the changes included here.

@guillett guillett requested a review from paulfitz September 24, 2025 14:29
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.

2 participants