ocket8888 commented on PR #6639: URL: https://github.com/apache/trafficcontrol/pull/6639#issuecomment-1093370818
> https://github.com/apache/trafficcontrol/pull/6639#discussion_r840659246 I don't know why responses aren't allowed to the conversations in this PR anymore, so I'm responding here > also it should probably be {name}:UPDATE since this is a put. that's actually a GET, though. The `.../approved` endpoint he mentioned is a PUT > I can change it to be a READ but it would need to be different than the CDNI-CAPACITY:READ and makes more sense to me that it would mirror the approved endpoint. what do you think? I think normally the way this is handled is the read-only operation has a <CODE><var>NAME</var>:READ</CODE> Permission and then the endpoint to actually do things with/to that data requires that Permission _and_ its own <code><var>NAME</var>:UPDATE</code> Permission (or `CREATE` or whatever's appropriate). So that way the data can be displayed to people who don't have Permission to change it. These CDNI endpoints are highly incongruous with our existing API structure and practices, normally if you really only wanted people who could manipulate the data to see it I'd be puzzled why they are two different endpoints instead of different methods on a single endpoint. So that's part of the issue is it's just hard to think about how these things are "normally" handled. But if it's not a spec requirement that only people with the ability to change it be allowed to see it, I think it's better to just be more flexible and add the READ Permission here as well as an extra Permission required by the manipulation endpoint, since that's more in-line with how the regular API works. -- 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]
