ocket8888 opened a new issue, #6830: URL: https://github.com/apache/trafficcontrol/issues/6830
## This Bug Report affects these Traffic Control components: - Traffic Ops ## Current behavior: `/user/current` validates the `role` field and will reject requests that specify a new Role with greater Permissions (or in old version PrivLevel) than the user's current Role - but even if that validation passes, it's not possible to use this endpoint to change Role. The request will succeed, but even in the response to that request, the user's Role remains unchanged. `/user/current` GET requests also always show `gid` and `uid` as `null`, even when they aren't. Curiously, it does allow the user to change these fields, and the responses to PUT requests that do so will show the correct values. Subsequent GET requests will show `null`. ## Expected behavior: `/user/current` shouldn't show the wrong value for fields, and if it's intended to be able to change a user's Role using it then that should work. If that's not intended, then the field should be ignored, not validated, and removed from the request documentation. ## Steps to reproduce: PUT to /user/current changing your Role to anything you have permission to change it to. Observe that it didn't happen. PUT to /user/current changing your uid and gid to anything non-null. Observe that both still appear to be `null` in GET responses. It is unknown if this is a regression or if this has just been broken forever, since `uid` and `gid` have no known use and changing a user's own Role is rare and generally not very advisable because they can only be taking permissions away from themselves - so it's possible this never worked and nobody noticed because nobody needed it to work. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
