You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a discussion with @mathuin and @Kennric we came to the conclusion that our query parameters allow for overly complex (and perhaps even malicious) queries to occur. This makes our lives harder in that we have to implement / maintain / test conceptually straining.
To help solve some of our problems we are going to simplify the query parameters by restricting use of only one of each type of query parameter in a given request. If more than one of the same query parameter is sent it will be discarded.
This results in a query who's maximum length is this:
GET /times?\
include_revisions=<bool>\
&include_deleted=<bool>\
&user=<username>\
&project=<project>\
&activity=<activity>\
&start=<date>\
&end=<date>
... which puts more strain on any system that uses our API (in that it has to make multiple calls to get, say times for multiple users) but makes the API itself quite a bit easier to implement and test, and hopefully adds the benefit of freeing up resources instead of encouraging bundled mega-requests ("I want the times from all 5000 of these individual employees please").
I'm fine with this. I don't think this adds complexity from client side, in fact it removes complexity for pymesync. It might add the need for a loop on front-end, but that is a non-issue. This also removes the need for in-line errors suggested in #57
In a discussion with @mathuin and @Kennric we came to the conclusion that our query parameters allow for overly complex (and perhaps even malicious) queries to occur. This makes our lives harder in that we have to implement / maintain / test conceptually straining.
To help solve some of our problems we are going to simplify the query parameters by restricting use of only one of each type of query parameter in a given request. If more than one of the same query parameter is sent it will be discarded.
This results in a query who's maximum length is this:
... which puts more strain on any system that uses our API (in that it has to make multiple calls to get, say times for multiple users) but makes the API itself quite a bit easier to implement and test, and hopefully adds the benefit of freeing up resources instead of encouraging bundled mega-requests ("I want the times from all 5000 of these individual employees please").
@Kennric @matthewrsj @LyonesGamer @athai thoughts?
We could further limit the use of these parameters, but the guiding principles here are as follows:
If we like that I can document it and work on implementation. Otherwise let's discuss.
The text was updated successfully, but these errors were encountered: