1. 06 4月, 2023 4 次提交
  2. 05 4月, 2023 1 次提交
  3. 30 3月, 2023 2 次提交
  4. 29 3月, 2023 2 次提交
    • R
      Remove support for redundant request media types in the API (#5874) · 409fac52
      Roman Donchenko 提交于
      Currently, every API endpoint that takes a request body supports (or at
      least declares to support) 4 media types:
      
      * `application/json`
      * `application/offset+octet-stream`
      * `application/x-www-form-urlencoded`
      * `multipart/form-data`
      
      Supporting multiple media types has a cost. We need to test that the
      various media types actually work, and we need to document their use
      (e.g., providing examples for each supported type). In practice, we
      mostly don't... but we still need to. In addition, the user, seeing the
      list of supported types, has to decide which one to use.
      
      Now, the cost could be worthwhile if the multiple type support provided
      value. However, for the most part, it doesn't:
      
      * `application/offset+octet-stream` only makes sense for the TUS
      endpoints. Moreover, for those endpoints it's the only type that makes
      sense.
      
      * `application/x-www-form-urlencoded` is strictly inferior to JSON. It
      doesn't support compound values, and it doesn't carry type information,
      so you can't, for example, distinguish a string from a null. It's
      potentially susceptible to CSRF attacks (we have protections against
      those, but we could accidentally disable them and not notice). Its main
      use is for form submissions, but we don't use HTML-based submissions.
      
      * `multipart/form-data` shares the downsides of
      `application/x-www-form-urlencoded`, however it does have a redeeming
      quality: it allows to efficiently upload binary files. Therefore, it has
      legitimate uses in endpoints that accept such files.
      
      Therefore, I believe it is justified to reduce the API surface area as
      follows:
      
      * Restrict `application/offset+octet-stream` to TUS endpoints and remove
      support for other types from those endpoints.
      
      * Remove `application/x-www-form-urlencoded` support entirely.
      
      * Restrict `multipart/form-data` support to endpoints dealing with file
      uploads.
      
      Note that I had to keep `multipart/form-data` support for `POST
      /api/cloudstorages` and `PATCH /api/cloudstorages/<id>`. That's because
      they accept a file-type parameter (`key_file`). I don't especially like
      this. Key files are not big, so the efficiency benefits of
      `multipart/form-data` don't matter. Therefore, I don't think we really
      need to support this type here; it would be more elegant to just use
      JSON and Base64-encode the key file contents. However, I don't have time
      to make that change right now, so I'm
      leaving it for another time.
      409fac52
    • A
      Fix export of a job from a task with multiple jobs (#5928) · ce635657
      Anastasia Yasakova 提交于
      Fixed #5927 
      ce635657
  5. 27 3月, 2023 1 次提交
  6. 24 3月, 2023 4 次提交
  7. 23 3月, 2023 1 次提交
  8. 22 3月, 2023 4 次提交
  9. 21 3月, 2023 1 次提交
  10. 20 3月, 2023 1 次提交
  11. 17 3月, 2023 1 次提交
  12. 16 3月, 2023 3 次提交
  13. 15 3月, 2023 3 次提交
  14. 14 3月, 2023 1 次提交
    • A
      Fix reset of attributes when moving a task to a project (#5764) · 10ffa610
      Anastasia Yasakova 提交于
      - Fixed reset of attributes when moving a task to a project
      
      Steps to reproduce the bug:
      
      1. Create a task with a couple of labels and attributes
      2. Annotate several frames in the task. Attributes should have
      non-default value.
      3. Create a project and copy the definition of labels with attributes
      4. Move the task to the project.
      5. Attributes should have default values after the action
      Co-authored-by: Nkirill-sizov <sizow.k.d@gmail.com>
      10ffa610
  15. 10 3月, 2023 1 次提交
    • R
      Set a custom User-Agent for queries made by CVAT and CVAT SDK (#5705) · 28aec51a
      Roman Donchenko 提交于
      This lets us:
      
      * Download images from hosts that block generic user agents (notably,
      Wikimedia sites).
      
      * Easily distinguish queries to `app.cvat.ai` made by CVAT SDK (for
      analytics).
      
      Also as a consequence of the implementation, CVAT can now reuse the
      connection when downloading multiple images from the same host.
      
      I can't really think of any benefits from using the custom user agent
      for types of requests that I didn't mention (i.e. hooks, OPA, nuclio),
      but for consistency I updated them all.
      28aec51a
  16. 09 3月, 2023 2 次提交
  17. 06 3月, 2023 1 次提交
  18. 02 3月, 2023 2 次提交
  19. 28 2月, 2023 1 次提交
  20. 24 2月, 2023 2 次提交
  21. 23 2月, 2023 1 次提交
  22. 22 2月, 2023 1 次提交