The reason he needs to use your guy's password is because peppy still hasn't developed an oauth system so you can log into the website yourself and pass authorization to the application. So you have to risk passing your password through a third party program in order to authorise in third party apps.
TL;DR:
Peppy has said he wants to make an oauth system, but wants to do it right(!) and is currently too busy maintaining the games source to work on it.
In the meantime peppy should implement a simple auth key for applications like this. Similar to this:
A modular system like this can easily be expanded and is just as secure as sessions. (As you can see the login failsafe for this app is a session hijack. Which has just as much power as a player login, where an api hijack can be limited by permissions and a revocation. Both are subject to expiration.)
Edit: To the developer: Release your source code if you are ever accessing players accounts outside of an oauth system or you are labeling your program as a potential phishing exploit.
TL;DR:
Peppy has said he wants to make an oauth system, but wants to do it right(!) and is currently too busy maintaining the games source to work on it.
In the meantime peppy should implement a simple auth key for applications like this. Similar to this:
(table: userAuth, col int uniqueID, col int userOsuID, col str devApiKey, col str userAuthKey, col time expiresOn)
1. User accesses app.
2. App requests auth, sends user to osu auth page with devApiKey and callback URL.
3. osu auth page requests the user to log in (or if already logged in skip) and ask the user to give application permission to access your account.
4. On deny send user to callback with userAuthKey 0. On accept generate userAuthKey and expiresOn, store them with devApiKey in db, send userAuthKey, userOsuID, and expiresOn to callback url.
5. Accept userAuthKey, userOsuID, and devApiKey as a replacement for userSession for Beatmap System/Forums/Messaging. Do not allow api sessions access to settings or donations. Return error if userAuthKey is expired or incorrect.
6. Add a simple revoke api page in settings that allows users to set the expiresOn on their own userAuthKey's to 0.
7. Ban api keys that abuse.
A modular system like this can easily be expanded and is just as secure as sessions. (As you can see the login failsafe for this app is a session hijack. Which has just as much power as a player login, where an api hijack can be limited by permissions and a revocation. Both are subject to expiration.)
Edit: To the developer: Release your source code if you are ever accessing players accounts outside of an oauth system or you are labeling your program as a potential phishing exploit.