Validate that common data parameter values between URL dynamic route segments and POST data are equal

[arschles]

No description provided.

[arschles]

I'm pushing this to beta4

[arschles]

@jackfrancis can you write a short summary for the work represented in this issue? A few small examples would also be helpful. Punting to RC1 for now

[jackfrancis]

For example, this route+handler definition:

r.Handle("/{apiVersion}/versions/{component}/{train}/{version}", handlers.PublishVersion(db)).Methods("POST").
        Headers(handlers.ContentTypeHeaderKey, handlers.JSONContentType)

handlers.PublishVersion performs the following business logic:

func PublishVersion(db *gorm.DB) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        componentVersion := types.ComponentVersion{}
        err := json.NewDecoder(r.Body).Decode(&componentVersion)
        if err != nil {
            log.Printf("Error decoding POST body JSON data (%s)", err)
            return
        }
        //TODO: validate request body parameter values for "component", "train", and "version"
        // match the values passed in with the URL
        routeParams := mux.Vars(r)
        componentVersion.Component.Name = routeParams["component"]
        componentVersion.Version.Train = routeParams["train"]
        componentVersion.Version.Version = routeParams["version"]
<truncated>

Essentially, it "throws away" the component.name, version.train, and version.version property values passed in w/ the request body and replaces those with the values present in the route URL.

This ticket is to consider validating that the property values included in the HTTP POST body data match those in the route URL. I suppose the scope is still TBD, but it'll be one of these:

• require that all 3 properties ("component", "train", "version") be present in the body data, and that they match their respective property values in the URL
• make the 3 properties optional in the body data, but if any of them are present, ensure that they match their respective values in the URL

I prefer the 1st approach, as it's easier to implement and it enforces more sane input requirements, in my opinion (a JSON representation of a ComponentVersion doesn't really make sense without having a "component name", and a "train", and a "version" string).

[arschles]

Requires #138 to be merged first. Bumping this from RC1 as it's not required for the release and can be pushed to production shortly thereafter.

[jackfrancis]

Post-Swaggergeddon we should validate that the above scenario is still correct. In any event, it's probably not high priority to sanity-enforce data items that are otherwise currently being thrown away.