-
Notifications
You must be signed in to change notification settings - Fork 19
Description
Expected vs actual behavior
Recently we ran into the following issue. An IDP user logged into the system and saw the "no projects found" page. They were then added into the appropriate group containing access to projects. They then refreshed the page and the normal homepage came up, however it was blank.
Looking at the network browser, it appeared that the organization and partner values were null.
Some users were able to bypass this issue by opening up a new browser in incognito mode or a private window, while others had to clear their cache before doing that. Still others couldn't bypass it at all until a certain time had passed.
The problematic area is from here:
dashboard/src/actions/Projects.js
Line 3 in d7cd410
| export function getProjects() { |
I assume that means that the localstorage has null values initialized in it and need to somehow be cleared out before the webpage will show again? Theoretically a logout should take care of this, but I guess Okta/Kratos prevents this? I do know that kratos has a session like regular local storage.
Is there a way to easily bypass this?
Steps to reproduce the bug
- Log into the webpage with Okta, see the "No projects found" page
- Create a project through the API
- Create a new group with a user assigned to the group and the group assigned to the project.
- Refresh the page
Are you using the latest version of the project?
You can check your version by running helm ls|grep '^<deployment-name>' or using pctl, pctl version, and provide the output.
VERSION: 0.1.0
BUILD: 0.1.0
BUILD-TIME: 1656329967
ARCH: darwin/amd64
What is your environment setup? Please tell us your cloud provider, operating system, and include the output of kubectl version --output=yaml and helm version. Any other information that you have, eg. logs and custom values, is highly appreciated!
Kubectl
clientVersion:
buildDate: "2022-08-23T17:44:59Z"
compiler: gc
gitCommit: a866cbe2e5bbaa01cfd5e969aa3e033f3282a8a2
gitTreeState: clean
gitVersion: v1.25.0
goVersion: go1.19
major: "1"
minor: "25"
platform: darwin/amd64
kustomizeVersion: v4.5.7
serverVersion:
buildDate: "2022-11-29T18:41:42Z"
compiler: gc
gitCommit: 52e500d139bdef42fbc4540c357f0565c7867a81
gitTreeState: clean
gitVersion: v1.22.16-eks-ffeb93d
goVersion: go1.16.15
major: "1"
minor: 22+
platform: linux/amd64
Helm
version.BuildInfo{Version:"v3.10.3", GitCommit:"835b7334cfe2e5e27870ab3ed4135f136eecc704", GitTreeState:"clean", GoVersion:"go1.19.4"}
(optional) If you have ideas on why the bug happens or how it can be solved, please provide it here
Removing the user from the group within paralus UI and then readding them manually got it to work.
- [ X] I've described the bug, included steps to reproduce it, and included my environment setup with all customizations.
- [ X] I'm using the latest version of the project.

