The RSP deployment at our Interim Data Facility is now open to members of the DP0.1 shared-risks delegate program, and with new users came new and exciting issues with the one thing everybody wants to do: log on! Based on user experience we made the following bugfixes and improvements now live at data.lsst.cloud.
-
Some users that belonged to a great number of GitHub teams could not log on. This has now been fixed. [^1]
-
Logging out now clears any existing GitHub authorisation information, allowing for easier recovery in case of problems and also matching user expectations for what should happen when they log out. [^2]
-
Users with non-Latin characters in their in their GitHub profile can now use RSP services such as the portal and notebook aspects [^3]
We greatly appreciate those of you who took the time to file Github Issues - you helped make the platform better for future users.
Click on the arrow below to expand the technical footnotes.
Here Be Geek
[^1]: We are currently using the membership of Github teams for authorisation information and have been doing so for some time on some of our internal deployments. When a user authenticates, we check what teams they belong to, and whether any of those teams are on the allow list for access to the particular deployment. Some users run into an issue where (1) they were members of so many teams that the GitHub API paginated the result when we asked "which teams does the user belong to and (2) none of the teams we were using for access controll were on the first page of results. We had not encountered this particular combination in testing. The authentication and authorisation component of the RSP now correctly pages through all returned pages looking for allowed teams.
[^2]: In some situations (for example if a user attempted to log in prior to accepting their invitation) the user is issued with an OAuth access token that allows them to log in, but does not allow them access to any of the RSP services. When the situation changes (in the case of the previous example after the user accepts their invitation), the user had to go through a number of steps to clear out their old token so that they could be issued with a better one. From now on, a user in such a situation need only log out and back in again: logging out of the RSP now clears the previously issued token.
[^3]: When a user logs in, the authentication and authorisation service collects some metadata about the user and forwards it to the various RSP services via HTTP headers. This included the name field in the user’s GitHub profile. When a user with a Unicode character in their name logged in, we discovered that one of our dependencies forces the encoding of those headers to Latin-1, raising an error. We can fix this properly by MIME-encoding the headers, but in the interest of a quick fix for the affected user and given the use of names was only cosmetic, we are now passing on the user’s username as their name. We have also added unit tests with names in a wide range of character sets to avoid such issues in the future.