Endpoints for authenticating an application with user credentials

[Osiris-Team]

Example: https://api.spigotmc.org/simple/0.2/index.php?action=login&username=John&password=JohnsPassword123 The above url responds with something like this:

{
  "access-token": "9hu88asch90asf79hasf89hsh89ßadh98ßas",
  "expiration-date": "timestamp in miliseconds"
}

The returned access-token can then be used for following requests by the application to do stuff on behalf of the user or fetch private user information like the bought plugins.

Alternatively, we could do it similar to how GitHub does it, by letting the user create access-tokens with specified permissions on spigotmc.org when logged in. The user then gives that token to the application, so there is no need of sharing the actual credentials.

My use case would be the following:

I have been working on a software called AutoPlug for some time. AutoPlug simplifies server maintenance and among other things, you can automatically update spigot plugins. Since there is no rest-api for authenticating users I can't provide premium plugin updating for my users, but I have found a way to simulate a headless browser via Java and use it to login my users to spigotmc.org. But this method is quite time-consuming, resource intensive and unnecessary. So it would be really advantageous for everyone if there was an endpoint like in the example above available.

[robertlit]

I think this is out of scope. Also, I'm pretty sure that what you're currently doing violates the rules.

And a few more things:

• The way you're suggesting is insecure, as users will have to give you passwords in plain text, which you will then send as a URL parameter. An example of a proper solution is to implement OAuth2 (which I believe would be out of scope).
• You only mentioned one endpoint, but to actually use the returned access token, multiple more endpoints will need to be added.

[Osiris-Team]

Also, I'm pretty sure that what you're currently doing violates the rules.

If you are referring to the simulated browser stuff, yes that would violate the rules and that's why I'm not doing it. All the other stuff is done over the spiget api.

The way you're suggesting is insecure, as users will have to give you passwords in plain text, which you will then send as a URL parameter.

Agree, OAuth is a WAY better solution, but as you said out of scope, since there is a lot of stuff the actual admins/mantainers of spigotmc.org would have to do. That's why I suggested this approach which isn't so bad either.

You only mentioned one endpoint, but to actually use the returned access token, multiple more endpoints will need to be added.

That could be true, but I wasn't in the mood of designing the whole system without approval from a contributor, if that makes sense for you.

[Osiris-Team]

Closing because of no response

[Phoenix616]

Why would you close an issue if it isn't solved yet? Just because nobody responds to it it doesn't mean that an issue doesn't eventually get worked on (maybe even by someone who noticed it in the list and wanted to PR) so I would request this issue to be re-opened.

As for the original issue: The easiest way would probably be to do it by generating an API key per user (or even multiple for different purposes) which then can be used to authenticate or even for detecting api abuse and blocking individual keys. Of course OAuth is nice but don't think really necessary for the start when it's just about accessing information. (Also this API wont really be user-facing anyways but just something that at most server admins would need so pointing towards the API key page and the config entry for specifying it)

One thing that should be kept in mind though is that API keys of banned users have to be invalidated.

As for my use case of authetnication: I personally would love the ability to read the purchasers list to more easily authenticate buyers for stuff like support channel and source code access. (Also downloading resources is/has been discussed here)

[jacobsandersen]

It is really annoying to have issues closed "because of no response". I am one person working on this in my free time, of which I have very little.

Authentication (log in/out) will not be built into this API. Use of API keys (authorization) probably will be. This API is meant to be read-only. The API keys would be managed by an external system, which has not been built yet.

It might be possible, once API keys are done, to download premium resources. Downloading resources through this API has been discussed but so far has reached no conclusions.

Sorry for the late response. I am a full time student. I have very little time to devote here.

[Osiris-Team]

No worries. Thanks for the answer.

[baticag]

This is actually great to see implemented especially for Premium resources.

[8MiYile]

How time have WebAPI it's look like Spotify's Development WebAPI oauth and download premium

and thx