Skip to content
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

UAA Client Improvements #3851

Open
philippthun opened this issue Jun 18, 2024 · 0 comments
Open

UAA Client Improvements #3851

philippthun opened this issue Jun 18, 2024 · 0 comments

Comments

@philippthun
Copy link
Member

Validation of User "Guids"

Cloud Controller accepts arbitrary strings (only rule: 1 to 200 characters long) as input for the "guid" of a user - which can either be a real UUID or an (OAuth) client ID. Although the POST /v3/users endpoint is for admins only, all org managers can create users by assigning them a role within their org. Currently there is no further validation with regards to allowed characters in the "guid"; there is also no check if the added "guid" already exists in UAA (either as a user's guid or a client's id).

Question: Should there be further validations (e.g. as part of the UserCreateMessage)? To be considered: v2 endpoints don't use this message class, but directly create the user (e.g. User.create).

Question: Would it make sense to send a request to UAA to validate the provided "guid"?

Categorization of UAA Errors

All UAA errors are presented as UaaUnavailable errors. This is misleading and hides some real errors coming from UAA (that might be caused by an incorrect call done by Cloud Controller). For other external components there are different error types, i.e. StagerUnavailable vs. StagerError, RunnerUnavailable vs. RunnerError and BlobstoreUnavailable vs. BlobstoreError.

Question: Would it make sense to introduce an UaaError (HTTP status code 500) and distinguish between temporary (e.g. connection) issues and other concrete (permanent) errors?

Retry Mechanism for Transient Errors

Currently all UAA errors are retried. Although this reduces problems due to temporary issues, it seems rather unnecessary for errors caused by a wrong request. Having a better categorization of errors (see above) would make it easier to decide which errors should be retried and which not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant