Backstage update #771
Backstage update #771
Conversation
See backstage-common 0.24.0 changelog
https://backstage.io/docs/backend-system/building-backends/migrating/#the-auth-plugin Add option to login with new guest auth provider or GitHub https://backstage.io/docs/auth/guest/provider/ https://backstage.io/docs/auth/#sign-in-configuration
GDYendell
force-pushed
the
backstage-update
branch
from
553d373 to
45cc39c
Compare
garryod
added
dependencies
| collators: | ||
| catalog: | ||
| schedule: | ||
| # Give the backend server a chance to initiaize before collators are executed |
There was a problem hiding this comment.
The timeout or the comment about the timeout? It was in search.tsx before.
There was a problem hiding this comment.
The comment on the timeout 😆 Wasn't a particularly serious review point
| target: ldap://ralfed.cclrc.ac.uk | ||
| bind: | ||
| dn: uid=ldap-reader-user,ou=people,ou=example,dc=example,dc=net | ||
| secret: dW5hdXRoZW50aWNhdGVkIExEQVAK |
There was a problem hiding this comment.
It is a fake secret because the field has to be provided, but the server is unauthenticated.
| SignInPage: props => ( | ||
| <SignInPage | ||
| {...props} | ||
| providers={[ | ||
| 'guest', | ||
| { | ||
| id: 'github-auth-provider', | ||
| title: 'GitHub', | ||
| message: 'Sign in using GitHub', | ||
| apiRef: githubAuthApiRef, | ||
| }, | ||
| ]} | ||
| /> | ||
| ), |
There was a problem hiding this comment.
Am I correct in thinking this shows up before the user is able to perform any other action? If so, can we somehow make guest the default and only require additional sign-in when a privileged action is requested (e.g. component template creation)?
There was a problem hiding this comment.
Yes it does, you have to click Enter as guest user when first launched. I don't know if that is possible, but I will investigate.
There was a problem hiding this comment.
Guests can go to Settings > Authentication Providers to login via GitHub.
We might need a custom auth resolver to automatically login as guest. This might also be a problem:
This provider makes all users share a single "guest" identity. This is useful for testing purposes and quickly getting started locally, but is not safe for use in production and that particular provider will refuse to work there.
There was a problem hiding this comment.
A custom auth resolver sounds like a good call
The shared guest identity isn't an issue for us as we run backstage in an immutable configuration. If you were to allow people to edit things in the UI it would certainly be an issue
This updates to use the new backend so that we get the new health check endpoints.