zrhoffman commented on pull request #5974: URL: https://github.com/apache/trafficcontrol/pull/5974#issuecomment-876112001
> So where we're getting the CDNs and where we're checking the CDNs would be two totally different areas of the code (which isn't great IMO). Since all "lock-safe" endpoints are either POST, PUT, or DELETE, the parameter identifying the resource will be almost always be unique to that resource. There could be an additional table like `locks_by_route` with 3 columns: * `resource_key` * `route` * `cdn_is_locked` and a CDN Locks middleware would be able to check if a given Route is already locked with respect to a given resource key without needing to derive which CDN that resource uses. This almost always means needing to know in advance which parameters to use for `resource_key` (as far as I know, this would be primary key in all cases except endpoints implementing `OptionsDeleter.DeleteKeyOptions()`), but there could be an additional table indicating which DB tables correspond to which TO Routes. In the case of resources implementing `OptionsDeleter.DeleteKeyOptions()` (Topologies and Regions only), there would need to be a row for each option returned by ``DeleteKeyOptions()` for that resource type. Since this approach would involve setting up infrastructure in Traffic Ops that we don't currently have, it wouldn't necessarily immediately save implementation time, though maybe it would be more maintainable long-term than calling `CheckIfCurrentUserCanModifyCDN()` from each affected handler. > The middleware would have to get those out of the request context (after the request has been "handled successfully" as far as the handler knows) to run the check (which might fail). If there is a CDN Locks middleware on some Routes, it would go at the end of the middlewares list (after `middleware.WrapPanicRecover()`. Since it is at the end of the middleware list, and since we'd be passing a custom middlewares list for each such route, calling `h(w, r)` from the CDN Locks middleware would always call the Route handler, meaning that if the CDN Locks check fails, calling `h(w, r)` could just be skipped. This PR aside, middlewares are very underused in Traffic Ops (we actually have 0 endpoints that use non-default middlewares, `Route.Middlewares[]` is nil or empty for all Routes listed in `routes.go`), so hopefully someone does make use of them at some point. -- 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]
