getting error 403 forbidden on ui and on the network tab "We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue."
Current Behavior
getting below error in the network tab in the developer's tool
Steps to Reproduce
- used below dependency track document to deploy dependency track using helm chart repo https://docs.dependencytrack.org/getting-started/deploy-kubernetes/
- after successfully deploying the dependency track. i implemented SSO using OIDC Connect protocol but getting above error while trying to login using OIDC connect below are the configuration done in the API-SERVER and FRONTEND manifest file
API-SERVER: - name: ALPINE_OIDC_ENABLED value: "true" - name: ALPINE_OIDC_ISSUER value: https://accounts.google.com - name: ALPINE_OIDC_CLIENT_ID valueFrom: secretKeyRef: name: dtrack-db-credentials key: clientID - name: ALPINE_OIDC_USERNAME_CLAIM value: email - name: ALPINE_OIDC_TEAMS_CLAIM value: groupList - name: ALPINE_OIDC_USER_PROVISIONING value: "true"
FRONTEND: - name: OIDC_CLIENT_ID valueFrom: secretKeyRef: name: dtrack-db-credentials key: clientID - name: API_BASE_URL value: https://ci-dev-dt.cp.manh.cloud - name: OIDC_ISSUER value: https://accounts.google.com - name: OIDC_LOGIN_BUTTON_TEXT value: Manh Users - name: OIDC_FLOW value: implicit
Expected Behavior
I am not supposed to get the 403 forbidden error on the UI. i am suppose to land on the dashboard page once i login to the page
Dependency-Track Version
4.11.7
Dependency-Track Distribution
Container Image
Database Server
PostgreSQL
Database Server Version
15
Browser
Google Chrome
Checklist
- [x] I have read and understand the contributing guidelines
- [x] I have checked the existing issues for whether this defect was already reported
I need this resolved as soon as possible. Any quick help would be greatly appreciated.
Looks like the requests meant for the REST API somehow end up at the frontend pod. I would recommend double-checking whether requesting https://ci-dev-dt.cp.manh.cloud/api/version from outside the cluster actually reaches the API server (you should get a JSON response).
If that doesn't work, review your ingress configuration. If you use the same host for frontend and API server, you need to make sure that all requests matching the /api path are forwarded to the API server.
@nscuro I have tried hitting the https://ci-dev-dt.cp.manh.cloud/api/version api from browser in my laptop and got the below response as expected i suppose.
{"version":"4.11.7","timestamp":"2024-08-14T12:37:10Z","systemUuid":"8b644aaa-4ddc-4162-89d4-d92962f62240","uuid":"6c958a55-2f1f-49f5-9b46-86d7f1624722","application":"Dependency-Track","framework":{"name":"Alpine","version":"2.2.5","timestamp":"2024-02-29T20:30:01Z","uuid":"389e4e81-225a-45b7-92bb-1e19e910e1c1"}}
below is my ingress configuration spec: rules:
- host: ci-dev-dt.cp.manh.cloud
http:
paths:
- backend: service: name: dtrack-dependency-track-api-server port: name: web path: /api pathType: Prefix
- backend: service: name: dtrack-dependency-track-frontend port: name: web path: / pathType: Prefix
what can we do next to fix it ?
@nscuro anything you can think we are missing ? please let us know because it is kinda urgency.
@nscuro after rechecking all the configuration again and again i am not able to figure the flaw. any help would be appreciated.
Does logging in as default admin user work?
If so, please check whether the OIDC user you tried logging in as was created. I suspect the 403 you're seeing is because the user is not part of any team, and hence has no permissions.
Also, you could try setting ALPINE_OIDC_TEAMS_DEFAULT=Administrators (for testing, don't leave it at Administrators):
https://github.com/DependencyTrack/dependency-track/blob/9d66e60d9a7189ade480a7d7460d05eb863c8986/src/main/resources/application.properties#L370-L374
@nscuro i have added the above property as suggested but getting the same error.
i can see in the api-server pod logs it is saying as below there is no error
Successful OpenID Connect login / username:
not sure what is going wrong ?
@nscuro and moreover you can see the below screenshots all the service call in the network tab is returning 200 status
@nscuro You were absolutely correct the oidc user was not assigned with any team and was not given any permission thats why i was getting the error. when i logged in as one of the managed user and assigned one team along with provided permission to it, it started working.
but how come it didn't work when added the ALPINE_OIDC_TEAMS_DEFAULT=Administrators property.
now my question is every time from my organization someone tries to access the dependency track application hosted by us for the first time will get this error then i have to manually assign a team to them and provide permission then only they can access.
how can we handle this automatically with out manual intervention.
and i would suggest there must be some proper logging so that this can be avoided.,
but how come it didn't work when added the ALPINE_OIDC_TEAMS_DEFAULT=Administrators property.
ALPINE_OIDC_TEAMS_DEFAULT only takes effect when the user is first provisioned, as in upon first successful login via OIDC. If the user already exists, the team is not assigned. This is because it can be intentional that certain users have no or different teams.
now my question is every time from my organization someone tries to access the dependency track application hosted by us for the first time will get this error then i have to manually assign a team to them and provide permission then only they can access.
This is what the team synchronization feature is for. But that relies on the IdP (in your case Google) to provide membership information in the ID token or /userinfo endpoint. DT can't pull team membership information out of thin air.
I don't personally use Google for OIDC, and judging by the team properties missing from the example Google config (https://docs.dependencytrack.org/getting-started/openidconnect-configuration/#example-configurations), I suspect they don't support inclusion of that data.
The ALPINE_OIDC_TEAMS_DEFAULT feature was added to work around IdP limitations like Google's.
and i would suggest there must be some proper logging so that this can be avoided.,
Did you even check the API server logs?
@nscuro one more question i am not sure why i am not seeing dependency graph even though in sbom dependency attribute is there.
@nscuro
Did you even check the API server logs?
i think you missed my previous comment where i mentioned what logs i can see in the api-server pod logs it is saying as below there is no error Successful OpenID Connect login / username: / IP Address: / User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
however could you please help with this one ?
one more question i am not sure why i am not seeing dependency graph even though in sbom dependency attribute is there. i checked previous issue logged here related to same issue and fix is given in 4.11.7 but i am using latest version 4.11.7 only but still seeing the same issue.
Thanks for your guidance and help.. really appreciated.
sbom
@nscuro could you please help with this ?
i am not sure why i am not seeing dependency graph even though in sbom dependency attribute is there. i checked previous issue logged here related to same issue and fix is given in 4.11.7 but i am using latest version 4.11.7 only but still seeing the same issue.