Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

🐛 Bug Report: TechDocs cookie authentication fails due to 'cookie was too large' #24420

Open
2 tasks done
JonasMH opened this issue Apr 22, 2024 · 3 comments · May be fixed by #24729
Open
2 tasks done

🐛 Bug Report: TechDocs cookie authentication fails due to 'cookie was too large' #24420

JonasMH opened this issue Apr 22, 2024 · 3 comments · May be fixed by #24729
Labels
area:techdocs Related to the TechDocs Project Area bug Something isn't working

Comments

@JonasMH
Copy link

JonasMH commented Apr 22, 2024 •
edited

📜 Description

When a user with a lot of groups tries to access a TechDocs page, it loads forever and opening the Dev Console Edge shows an error This attempt to set a cookie via a Set-Cookie header was blocked because the cookie was too large. The combined size of the name and value must be less than or equal to 4096 characters
image

👍 Expected behavior

It should load and show the TechDocs page to the user

👎 Actual Behavior with Screenshots

It loads forever

👟 Reproduction steps

  1. Login to Backstage as a user with a lot of groups or other information that increases the size of the JWT Token to over 4096 characters
  2. Try to access a TechDocs page
  3. The page loads forever
  4. In the Developer Console Network Tab you can see:
    a. The request to /api/techdocs/.backstage/auth/v1/cookie seem to have went okay, but when viewing the details it shows the warning cookie too large as a small warning triangle next to the Set-Cookie response header
    b. It fails to load a TechDocs related .css file with a 401 Unauthorized due to missing cookie

📃 Provide the context for the Bug.

The reason for the large JWT tokens in our deployment is due to a narrow scoped RBAC setup, where each component has a AD Group controlling who has access to it. Maybe there's a better way to include this information than through the JWT Token ?

🖥️ Your Environment

OS: Linux 5.15.146.1-microsoft-standard-WSL2 - linux/x64
node: v20.11.1
yarn: 4.1.1
cli: 0.26.4 (installed)
backstage: 1.26.1

Dependencies:
@backstage/app-defaults 1.5.4
@backstage/backend-app-api 0.6.2, 0.7.0
@backstage/backend-common 0.21.7
@backstage/backend-defaults 0.2.17
@backstage/backend-dev-utils 0.1.4
@backstage/backend-openapi-utils 0.1.10
@backstage/backend-plugin-api 0.6.17
@backstage/backend-tasks 0.5.22
@backstage/backend-test-utils 0.3.7
@backstage/catalog-client 1.6.4, 1.6.3
@backstage/catalog-model 1.4.5
@backstage/cli-common 0.1.13
@backstage/cli-node 0.2.5
@backstage/cli 0.26.4
@backstage/config-loader 1.8.0
@backstage/config 1.2.0
@backstage/core-app-api 1.12.4
@backstage/core-compat-api 0.2.4
@backstage/core-components 0.13.10, 0.14.4
@backstage/core-plugin-api 1.9.2
@backstage/dev-utils 1.0.31
@backstage/errors 1.2.4
@backstage/eslint-plugin 0.1.7
@backstage/frontend-plugin-api 0.6.4
@backstage/integration-aws-node 0.1.12
@backstage/integration-react 1.1.26
@backstage/integration 1.10.0, 1.9.1
@backstage/plugin-api-docs 0.11.4
@backstage/plugin-app-backend 0.3.65
@backstage/plugin-app-node 0.1.17
@backstage/plugin-auth-backend-module-atlassian-provider 0.1.9
@backstage/plugin-auth-backend-module-aws-alb-provider 0.1.9
@backstage/plugin-auth-backend-module-azure-easyauth-provider 0.1.0
@backstage/plugin-auth-backend-module-bitbucket-provider 0.1.0
@backstage/plugin-auth-backend-module-cloudflare-access-provider 0.1.0
@backstage/plugin-auth-backend-module-gcp-iap-provider 0.2.12
@backstage/plugin-auth-backend-module-github-provider 0.1.14
@backstage/plugin-auth-backend-module-gitlab-provider 0.1.14
@backstage/plugin-auth-backend-module-google-provider 0.1.14
@backstage/plugin-auth-backend-module-microsoft-provider 0.1.12
@backstage/plugin-auth-backend-module-oauth2-provider 0.1.14
@backstage/plugin-auth-backend-module-oauth2-proxy-provider 0.1.10
@backstage/plugin-auth-backend-module-oidc-provider 0.1.8
@backstage/plugin-auth-backend-module-okta-provider 0.0.10
@backstage/plugin-auth-backend-module-pinniped-provider 0.1.11
@backstage/plugin-auth-backend 0.22.4
@backstage/plugin-auth-node 0.4.11, 0.4.12
@backstage/plugin-auth-react 0.1.0
@backstage/plugin-catalog-backend-module-bitbucket-server 0.1.31
@backstage/plugin-catalog-backend-module-msgraph 0.5.25
@backstage/plugin-catalog-backend-module-scaffolder-entity-model 0.1.15
@backstage/plugin-catalog-backend-module-unprocessed 0.4.4
@backstage/plugin-catalog-backend 1.21.1
@backstage/plugin-catalog-common 1.0.22
@backstage/plugin-catalog-graph 0.4.4
@backstage/plugin-catalog-import 0.10.10
@backstage/plugin-catalog-node 1.11.1
@backstage/plugin-catalog-react 1.11.3
@backstage/plugin-catalog-unprocessed-entities-common 0.0.1
@backstage/plugin-catalog-unprocessed-entities 0.2.3
@backstage/plugin-catalog 1.19.0
@backstage/plugin-devtools-backend 0.3.3
@backstage/plugin-devtools-common 0.1.9
@backstage/plugin-devtools 0.1.13
@backstage/plugin-events-node 0.3.3
@backstage/plugin-explore-common 0.0.2
@backstage/plugin-github-actions 0.6.15
@backstage/plugin-home-react 0.1.12
@backstage/plugin-home 0.7.3
@backstage/plugin-kubernetes-backend 0.17.0
@backstage/plugin-kubernetes-common 0.7.5
@backstage/plugin-kubernetes-node 0.1.11
@backstage/plugin-kubernetes-react 0.3.4
@backstage/plugin-kubernetes 0.11.9
@backstage/plugin-org 0.6.24
@backstage/plugin-permission-backend-module-allow-all-policy 0.1.14
@backstage/plugin-permission-backend 0.5.41
@backstage/plugin-permission-common 0.7.13
@backstage/plugin-permission-node 0.7.28
@backstage/plugin-permission-react 0.4.22
@backstage/plugin-proxy-backend 0.4.15
@backstage/plugin-scaffolder-backend-module-azure 0.1.9
@backstage/plugin-scaffolder-backend-module-bitbucket-cloud 0.1.7
@backstage/plugin-scaffolder-backend-module-bitbucket-server 0.1.7
@backstage/plugin-scaffolder-backend-module-bitbucket 0.2.7
@backstage/plugin-scaffolder-backend-module-gerrit 0.1.9
@backstage/plugin-scaffolder-backend-module-gitea 0.1.7
@backstage/plugin-scaffolder-backend-module-github 0.2.7
@backstage/plugin-scaffolder-backend-module-gitlab 0.3.3
@backstage/plugin-scaffolder-backend 1.22.4
@backstage/plugin-scaffolder-common 1.5.1
@backstage/plugin-scaffolder-node-test-utils 0.1.3
@backstage/plugin-scaffolder-node 0.4.3
@backstage/plugin-scaffolder-react 1.8.4
@backstage/plugin-scaffolder 1.19.3
@backstage/plugin-search-backend-module-catalog 0.1.22
@backstage/plugin-search-backend-module-explore 0.1.21
@backstage/plugin-search-backend-module-pg 0.5.26
@backstage/plugin-search-backend-module-techdocs 0.1.22
@backstage/plugin-search-backend-node 1.2.21
@backstage/plugin-search-backend 1.5.7
@backstage/plugin-search-common 1.2.11
@backstage/plugin-search-react 1.7.10
@backstage/plugin-search 1.4.10
@backstage/plugin-techdocs-backend 1.10.4
@backstage/plugin-techdocs-module-addons-contrib 1.1.9
@backstage/plugin-techdocs-node 1.12.3
@backstage/plugin-techdocs-react 1.2.3
@backstage/plugin-techdocs 1.10.4
@backstage/plugin-user-settings 0.8.5
@backstage/release-manifests 0.0.11
@backstage/repo-tools 0.8.0
@backstage/test-utils 1.5.4
@backstage/theme 0.4.4, 0.5.3
@backstage/types 1.1.1
@backstage/version-bridge 1.0.8

👀 Have you spent some time to check if this bug has been raised before?

  • I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

Are you willing to submit PR?

None
@JonasMH JonasMH added the bug Something isn't working label Apr 22, 2024
@github-actions github-actions bot added the area:techdocs Related to the TechDocs Project Area label Apr 22, 2024
@Rugvip
Copy link
Member

Rugvip commented Apr 22, 2024

We've implemented the starting point for fixing this more permanently through the new UserInfoService which moves this information out of the user token, https://github.com/backstage/backstage/tree/master/beps/0003-auth-architecture-evolution#userinfoservice-interface. It needs more implementation in the auth backend though, which isn't on our immediate roadmap.

Short term I'd recommend that you limit the number of ownership entity refs, although I'd also recommend this as a long-term goal too. The ownership entity refs are intended to point to groups that exist in your org that are able to own entities in the catalog, which entities then point to using the owner field and relation.

@kuangp
Copy link
Member

kuangp commented Apr 22, 2024

It needs more implementation in the auth backend though, which isn't on our immediate roadmap.

Kind of bummed to hear that this is not going to be finished being flushed out as part of the original BEP 😞
This is significantly affecting us as well and was really looking forward to being able to re-enable auth for techdocs ...

The ownership entity refs are intended to point to groups that exist in your org that are able to own entities in the catalog, which entities then point to using the owner field and relation.

This wasn't viable for us and probably for some other adopters too since we rely on these ownership claims to drive permissions for various plugins even if these groups themselves aren't owners of any entities in the catalog

@Rugvip do you mind laying out what's left to be implemented to get this fully working? I might take a stab at this when I have some spare time

@freben
Copy link
Member

freben commented Apr 22, 2024

@kuangp

backstage/plugins/auth-backend/src/identity/router.ts

Line 78 in 2d8d740

router.get('/v1/userinfo', async (req, res) => {

This implementation would change, to read the user info out of a new database table instead, keyed by the userEntityRef. The auth backend token issuance code should be updated to store all important user info upon each sign in (or rather, each token issuance?). At least the ownership refs, but in the future maybe more than that. And leave them out of the token itself.

Regarding the number of refs though: Even if you got rid of the token size issue, you'd still be paying a hefty cost for making these lists massive. In permissions checks etc these get translated to increasingly complex queries that affect the catalog etc.

While building this user info feature, would it instead be useful to return those "special" permissions strings as auxiliary data that the user info services retrieves, and which isn't mingled with the ownership claims themselves and their semantics? The vehicle for that could be custom token claims that just get stripped out and stored in the db, but perhaps the data types could instead be changed around the interaction surfaces here (the ctx methods and the sign in resolver etc) to make explicit room for the new user info mechanism?

@kuangp kuangp linked a pull request May 10, 2024 that will close this issue
Open
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area:techdocs Related to the TechDocs Project Area bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(userInfo): implement persisting user info to support limited tokens kuangp/backstage
4 participants
@JonasMH @freben @Rugvip @kuangp