osu-api
osu-api copied to clipboard
ppy
Login system
It would be useful to be able to implement the osu! user database into third party tools via API. This would allow applications that require an user db to use the one from osu! , making it easier for users (as they don't have to register again), more secure (as emails, passwords and private stuff only needs to be stored in one server) and simpler for developers (making register and login forms way shorter).
Oh yeah, some kind of authentication via osu!account would be a really good idea (especially osu!droid, which may, or may not be finally developed)
Wouldn't this be pretty heavy going on Peppy's hardware, if it gets used a lot?
Not more than if lots of people login on the official page. It'd do the same work; the only thing that would change is that, instead of setting sessions and cookies and all that stuff, it would print something that certifies it's the right user (like the userid).
(And, as a fun fact, it'd require 1 less call and give way less info than if you called Facebook's API for something)
It would be the same work, but it'd be /more/ than usual. That's what I meant.
if it gets more than 400,000 requests a second i might have problems. is this going to happen?
Even if it did, I'll know far enough ahead of time to scale up. Systems have no limits – ever. You are introducing problems where they don't and won't exist.
putting up an OAuth 2.0 server would probably the easiest solution here as things such as twitter or google us that since quite a while now and therefore most people writing web services might already have some simple OAuth clients running.
This could be used for example to share the same account on all platforms (iOS, android etc.) So you could for example check for specific services and list them under the osu! profile page, which then would turn into a hub that's orientating around the osu! world and it's individual user. This could be used by the services in case of osu!stream to list their stats the same way that they're currently able to see it for the computer version. (but that should be limited further as it also contains some risks for misuse)
This of course is just the tip of the iceberg if you ask me. However I think that this could go out of this API's scope pretty fast, unless peppy provides it in a pretty swiftly way.
I really hope that this will be done in one way or another (would save me some time to build my own userdb which then would just extend on the things provided by the basic osu! account instead of re-inventing all that register/login cycle)
I think there's another similar thread requesting this somewhere, where I agreed that OAuth would be awesome. I'd really like to see it done. Implementation (properly) will take a bit of time though, and as you know, I'm pretty busy trying to get some lingering features out at the moment.
Will see what can be done, though! I'm constantly trying to make things happen faster.
Hm, nice i could use OAuth to store downloaded packs in a better more permanent way.
I'm just going to "sign" this request. A simple user verification service would really benefit the IC project. (Being able to verify user's before they enter matchmaking.)
In an effort to not let this go stale, I'm going to look at setting up a bounty for an OAuth implmentation in osu-web's new API offering.
One of the main things that has held me back is whether we want to do OAuth 1 or 2. I realise that 2 is pretty standard these days (though not RFC stadard; google and facebook have custom changes/additions) but that doesn't necessarily mean it's what we want. OAuth 1 can be simpler to implement and may serve us well enough for what we want.
Rather than deciding myself, let's hear from anyone who is actually planning to use this API functionality to authenticate users on their own projects: which one works better for you?
OAuth 2 for sure; several of the libraries and tools I use simply don't support 1 any more for some reason.. Although, even better if you can support both, but that could be hard. On 15 Feb 2016 12:28, "Dean Herbert" [email protected] wrote:
In an effort to not let this go stale, I'm going to look at setting up a bounty for an OAuth implmentation in osu-web's new API offering.
One of the main things that has held me back is whether we want to do OAuth 1 or 2. I realise that 2 is pretty standard these days (though not RFC stadard; google and facebook have custom changes/additions) but that doesn't necessarily mean it's what we want. OAuth 1 can be simpler to implement and may serve us well enough for what we want.
Rather than deciding myself, let's hear from anyone who is actually planning to use this API functionality to authenticate users on their own projects: which one works better for you?
— Reply to this email directly or view it on GitHub https://github.com/ppy/osu-api/issues/1#issuecomment-184186558.
I'm definitely going to use this for ppaddict. I'd be fine with either standard. On Feb 15, 2016 1:28 PM, "Dean Herbert" [email protected] wrote:
In an effort to not let this go stale, I'm going to look at setting up a bounty for an OAuth implmentation in osu-web's new API offering.
One of the main things that has held me back is whether we want to do OAuth 1 or 2. I realise that 2 is pretty standard these days (though not RFC stadard; google and facebook have custom changes/additions) but that doesn't necessarily mean it's what we want. OAuth 1 can be simpler to implement and may serve us well enough for what we want.
Rather than deciding myself, let's hear from anyone who is actually planning to use this API functionality to authenticate users on their own projects: which one works better for you?
— Reply to this email directly or view it on GitHub https://github.com/ppy/osu-api/issues/1#issuecomment-184186558.
OAuth 2. I've seen libraries where OAuth 1 is deprecated, or completely removed, and it feels a bit backwards to go with the older standard.
OAuth 1 has been deprecated for nearly 4 years, with many security flaws present.
https://developers.google.com/identity/protocols/OAuthForWebApps
I've read up a bit, and I'm kinda split between both. One makes things easier as long as you use SSL, other isn't adapted for applications outside of web browsers. One requires more effort than the other to set up.
Personally I don't mind which one is used (there are libraries for both, and when there's a will there's a way). After reading a bit about OA2, it seems easy to use and understand. A note about requiring HTTPS support might be needed, though.