-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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.
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
🐛 Bug Report: Error 403 when accessing catalog using GitLab auth method #24503
Comments
Updated to Backstage 1.27.1 and problem persists, any idea? |
Hmm, do you have some custom auth setup or other middleware as part of your setup? For example the following request does not have any code path that returns a 403 in a standard setup afaik: |
Hello, I don't have a custom auth. I'm using GitLab provider offered by Backstage. I don't have a custom Middleware, I'm using in permissions.ts the ExamplePermissionPolicy that comes with Backstage The strange thing here is that when using Guest access I don't have any problem, but git GitLab access, I'm getting 403 trying to read the catalog without any custom middleware or anything similar |
It seems to be something with Permissions framework, because changing in app-config.yaml to permissions false it is working. Checking again, I have the ExamplePermissionPolicy with a change, allow all if user is logged in, and allow specific components if user is not logged in (Guest). Doing some tests with console.logs, if user is not present (guests) I'm entering to that policy and returning the desired components without any problem. But with user present, it isn't entering into the policy, so it is crashing in some point before checking the middle framework policy. All was working before 1.26 and I have it working with 1.25 in another branch. But in the branch where I'm updating to 1.26 (and now 1.27) it seems there is an incompatibility or a breaking change with permissions and GitLab Auth resolver (or the Auth in general...) The permissions plugin (https://backstage.io/docs/permissions) still using old backend way.... probably the problem is related with that |
Solved, after reading (#24517 (comment)) message, I reviewed again the Migrating to new backend guide, and a new section about migration Permissions is available (https://backstage.io/docs/backend-system/building-backends/migrating/#the-permission-plugin) I performed that guide some versions ago, and the changelog of Backstage, Permissions documentation and plugin changelog file... no mention about that new 'alpha' version that is needed to still using permission framework. As an advice, please notify that in documentation! |
Thanks for documenting your solution @javiermartingonzalez I had the same issue and this helped! |
📜 Description
After upgrading Backstage form 1.25.0 to 1.26.4 I'm not able to get the entities in the front using my GitLab account.
I'm able to access to entities successfully using Guest account but I'm getting a 403 error when logged in with my GitLab user. I'm using the new backend system.
I only updated to new release and also changed the imports to backstage-community. No more changes.
👍 Expected behavior
To be able to get the entities in catalog logged in with my GitLab account in the same way that Guest access.
👎 Actual Behavior with Screenshots
I'm getting an error 403 when trying to get entities from catalog.
The backend log says:
I'm using the new backend system, importing permission plugin as legacyPlugin with ALLOW policy:
With guest user I'm getting 200 code and the catalog is displayed on the screen
The login is OK, I'm able to access to my GitLab username and read info about Ownership from GitLab, but anyting more due to permission error
👟 Reproduction steps
📃 Provide the context for the Bug.
I have in my app-config.yaml from 1.25.0 the following key (need to be able to call getEntities from a quartz job in my backend):
And my resolver for GitLab is:
🖥️ Your Environment
👀 Have you spent some time to check if this bug has been raised before?
🏢 Have you read the Code of Conduct?
Are you willing to submit PR?
None
The text was updated successfully, but these errors were encountered: