-
Notifications
You must be signed in to change notification settings - Fork 889
Organization ID is not available #13906
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
Comments
@Emyrk thoughts? |
I think this is a UI bug. @aslilac? I will take a look too. |
I wonder if there is a caching issue on the FE code. The value comes from here: Line 376 in e8c1315
@emouawad if you force refresh your page to clear any page caching, does the issue persist? And if so, what is the value of the Curious if the |
|
Incognito mode. Could that be headers related? i wonder why it has different outcome depends which ingress i choose. Btw i tested older versions - it still fails with a generic error - newer versions are handling the error better though. |
@emouawad huh, so you are not authenticated and you are getting that error. Do you have a network request that ends in
What is "better"? @aslilac has made a PR that drops the possibility of that error from occurring, when that patch makes it's way to live. |
YES not authenticated yet, and new incognito window and cleared the cookies. Yeh, i noticed the PR, i can retest as soon as this is deployed - meanwhile these are the calls if it helps: https://coder.website.com/api/v2/users/me {
"error": true,
"code": 401,
"message": "Unauthorized",
"description": "The requested page needs a username and a password"
} https://coder.website.com/api/v2/users/first {
"error": true,
"code": 404,
"message": "Not Found",
"description": "The server can not find the requested page"
} https://coder.website.com/api/v2/authcheck {
"error": true,
"code": 401,
"message": "Unauthorized",
"description": "The requested page needs a username and a password"
} |
@emouawad appreciate all the data. The new PR just removes that code (was dead code anyway), so it should be fixed when it goes live. Nothing seems obvious from what you sent, I was curious if there was some strange auth state with the cookies going on, but that does not seem to be the case. |
Hmm. @Emyrk we could replace this line with |
@aslilac the line was changed to |
yes, but we did that change after the release, so the 2.13 branch still looks like this: https://github.com/coder/coder/blob/release/2.13/site/src/modules/dashboard/DashboardProvider.tsx#L47 |
@emouawad these changes should be available in next mainline release (7th of August) you can test them now using |
@matifali Still reproducible with ghcr.io/coder/coder-preview:main-2.13.1-devel-a8e6e89f6 Unexpected Application Error! |
I'm digging around a little bit, and I'm wondering if there might be an issue with what we're sending from the server. As in, we're sending a valid JSON value, and it's fully defined – but it happens to be of a type that the frontend isn't expecting Tomorrow I'm going to do some more digging. More contextThe minified We have checks in place to ensure that the UI will be stuck in a loading state if the value is ever undefined (especially during the initial loading). The UI is getting past the loading state no problem, though, and I don't see a way for an undefined value to ever slip through. But if we're accidentally sending an incorrect type back, that would be able to bypass the checks while still causing the |
/v2/experiments and /v2/appearance is returning 401 /v2/entitelements is returning {
"features": {
"access_control": {
"entitlement": "not_entitled",
"enabled": false
},
"advanced_template_scheduling": {
"entitlement": "not_entitled",
"enabled": false
},
"appearance": {
"entitlement": "not_entitled",
"enabled": false
},
"audit_log": {
"entitlement": "not_entitled",
"enabled": false
},
"browser_only": {
"entitlement": "not_entitled",
"enabled": false
},
"control_shared_ports": {
"entitlement": "not_entitled",
"enabled": false
},
"custom_roles": {
"entitlement": "not_entitled",
"enabled": false
},
"external_provisioner_daemons": {
"entitlement": "not_entitled",
"enabled": false
},
"external_token_encryption": {
"entitlement": "not_entitled",
"enabled": false
},
"high_availability": {
"entitlement": "not_entitled",
"enabled": false
},
"multiple_external_auth": {
"entitlement": "not_entitled",
"enabled": false
},
"multiple_organizations": {
"entitlement": "not_entitled",
"enabled": false
},
"scim": {
"entitlement": "not_entitled",
"enabled": false
},
"template_rbac": {
"entitlement": "not_entitled",
"enabled": false
},
"user_limit": {
"entitlement": "not_entitled",
"enabled": false,
"actual": 1
},
"user_role_management": {
"entitlement": "not_entitled",
"enabled": false
},
"workspace_batch_actions": {
"entitlement": "not_entitled",
"enabled": false
},
"workspace_proxy": {
"entitlement": "not_entitled",
"enabled": false
}
},
"warnings": [],
"errors": [],
"has_license": false,
"trial": false,
"require_telemetry": false,
"refreshed_at": "2024-07-24T04:42:38.327141842Z"
} |
@emouawad are you running this deployment behind a proxy or anything? I know the |
ok, well this is definitely the problem in the debugger screenshot you shared above, that can you try |
Issue solved now by removing the ingress-nginx default-backend that redirected 401 to a custom web page. (Not newly introduced) - There must have been a change on coder that affected this - previously was working fine with the default redirect in place. Thanks for helping! Closing. |
Uh oh!
There was an error while loading. Please reload this page.
On the home page, before login:
Unexpected Application Error!
Organization ID is not available.
Github authentication enabled.
Version:
ghcr.io/coder/coder:v2.13.0
Used env variables:
What is Organization ID: a github or a coder organization?
From the docs, tried to find if this is a config i can set in coder, nothing!
Weirdly enough:
I run this in kubernetes:
which led me to think: is this a headers issue?
The text was updated successfully, but these errors were encountered: