-
Notifications
You must be signed in to change notification settings - Fork 50
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
Fix visibleGroups is undefined error #77
Conversation
@@ -52,7 +52,7 @@ class Splash extends React.Component { | |||
|
|||
<HugeSpacer/> | |||
|
|||
{this.props.user && <UserGroups user={this.props.user}/>} | |||
{this.props.user && this.props.user.visibleGroups && <UserGroups user={this.props.user}/>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little confused here how/why this.props.user
was defined when there was no logged-in user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
user
is getting passed to the Splash component via the UserDataWrapper component, which by default is undefined.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, so looking closer, what's happening is that I have an existing login session (like most of our users will) but it lacks the visibleGroups
attribute because that's only added by your previous PR. In order to get the new attribute with the current code, a person has to logout and log back in again. We can either guard against the missing attribute everywhere (a little ugly), or could put the computation somewhere else so it happens every time, not only in the login flow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right. @jameshadfield initially pointed that out as a consequence of moving the visibleGroups logic inside the setup of OAuth2Strategy
.
I now recall that was the error I encountered in testing and fixed by logging in and out again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there no third solution where, now that the splash page is no longer broken, we can tell logged-in users to log in and out again? 😄
edit: I realize now that we will not want to make users log in and out every time they get added to a new group. So this is not a real solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
edit: I realize now that we will not want to make users log in and out every time they get added to a new group. So this is not a real solution.
The Cognito groups for a user are (as I understand the code) only fetched when a user logs in, so I don't think it's possible (as currently implemented) to see a new cognito group without logging in again
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Cognito groups for a user are (as I understand the code) only fetched when a user logs in, so I don't think it's possible (as currently implemented) to see a new cognito group without logging in again
Correct. We can improve this in the future by refreshing user details from Cognito on ~every request (or, ideally, with some short-lived cache).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I describe the issue a bit more in my reply to your comment.
Separately, the /users/trs page is also broken for me when I have an existing login session.
@@ -52,7 +52,7 @@ class Splash extends React.Component { | |||
|
|||
<HugeSpacer/> | |||
|
|||
{this.props.user && <UserGroups user={this.props.user}/>} | |||
{this.props.user && this.props.user.visibleGroups && <UserGroups user={this.props.user}/>} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, so looking closer, what's happening is that I have an existing login session (like most of our users will) but it lacks the visibleGroups
attribute because that's only added by your previous PR. In order to get the new attribute with the current code, a person has to logout and log back in again. We can either guard against the missing attribute everywhere (a little ugly), or could put the computation somewhere else so it happens every time, not only in the login flow.
e8169d2
to
aae1c22
Compare
aae1c22
to
393cae0
Compare
I moved the logic for determining |
393cae0
to
33b9d60
Compare
I'm still getting a console error when logged out:
I'm currently still investigating a working solution. edit: fixed |
In further testing of #74, we found an error when a user is logged-out that prevented the splash page of nextstrain.org from loading. Move the logic for determining which groups are visible to a user into the `/whoami` endpoint. Send the resulting `visibleGroups` as an additional key in the json load sent by this endpoint. Handle the additional `visibleGroups` object accordingly.
33b9d60
to
2d1f3b6
Compare
Thanks for fixing this, @kairstenfay. Merged! |
In further testing of #74, we found an error when a user is logged-out
that prevented the splash page of nextstrain.org from loading.
Fix the error by checking if visibleGroups is defined in addition to
user before rendering the
<UserGroups>
component.