Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ore V2 API design #449

Open
progwml6 opened this issue Feb 25, 2018 · 1 comment
Open

Ore V2 API design #449

progwml6 opened this issue Feb 25, 2018 · 1 comment

Comments

@progwml6
Copy link
Member

This is subject to negotiation as to the order of implementation, and what other things are considered high priority. All v2 endpoints should be in swagger or openapi. other sponge projects using these apis will rely on auto generated clients based on these api definition files.

All endpoints except potentially download should require tokens

Priority endpoints to implement equivalents of in v2 api

@phit
Copy link

phit commented Jun 17, 2019

Wanted to write down my thoughts in the API right now:

  1. Consider making sessions optional for public use, they add no purpose for us. People can simply create new sessions on a new IP at any point in time to bypass any form of rate limiting you could impose on a session. I would suggest simply rate-limiting public users by IP address and not session key. If people do wanna use sessions on public use, fine but I don't see an argument for enforcing it.

  2. Currently after receiving your session the HTTP standard Authorization header is being used, there's a few issues with this approach how it is right now:

    • some libraries add standard handling for this header and may simply not support our obviously non-standard schema
    • if we stick to using this header we need to follow the spec, see https://stackoverflow.com/questions/7802116/custom-http-authorization-header/11420667#11420667
      Authorization: ApiSession key > Authorization: OreAuth session=key
      OreAuth and session are placeholders we could change that to whatever we desire really, we just need to stick to the spec of the standard header.

    What I would suggest instead is just creating our own header, this will avoid any potential conflicts. I would suggest: OreSession: key
    I also read the linked issues for using JWT, but I agree this is currently probably not needed.

@felixoi felixoi pinned this issue Jun 17, 2019
@Katrix Katrix modified the milestones: v2.0.0-M1, v2.0.0 Aug 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants