no check for excess/unrecognized query parameters in req.Filter

[bennetyee]

https://github.com/oasislabs/developer-gateway/blob/9d015420837e791581ecbaa9f7c63272d9394249/api/v0/event/handler.go#L66

There should probably be a len(query) == 1 or similar check to ensure that there are no other parameters than "address". This is debatable wrt whether we intend to expand the filter interface soon, but some (documented) notion of a set of filter parameters at each interface version would be good. It seems unlikely that we would accidentally run a v0 interface (old docker image?) and ignore filter parameters from a v1 or higher client when we should report an error, but that would be good defensive programming.

[willscott]

auth plugins the developer writes may also inspect the http request as a way of conveying other information about the requesting user. as such, i don't think we need to hard-fail on unrecognized query parameters

[bennetyee]

does the auth plugin affect this? this is a quoted set of parameters, under filter, e.g., https://foo/bar/baz?p1=abc&p2=def&filter=stuff%3Dstuff-value%26other-stuff%3Dother-stuff-value&p4=ghi and it is the filter parameter with encoded stuff=stuff-value&other-stuff=other-stuff-value that is being decoded here, and filter should not be messed with by plugins.

maybe i'm confused about how parameters are parsed and there's no nesting. digging/learning....

[bennetyee]

Just notes / draft comments to myself here for now.

There is a whole web server here and we seem to be using a JSON decoder (HttpJsonHander) to decode the http.Request request body, after which the Filter is URL parameter parsed. Both Filter and Events of SubscribeRequest are defined in api/v0/event/entity.go and the annotation json:"events"etc forces lower-case names.