I agree asking for passwords is bad, but he'd probably have gotten cooperation from third parties much more quickly if he were following OAuth, OAuth2 or some other widely used standard. Forcing others to write bespoke code to handle a weird non-standard auth, however simple, is a major impediment to people using the Pinboard API.<p>Also, promising to break working integrations with the "ban hammer" seems like a poor reward to give users for alerting you to a problem. If a user values the integration more than the security of their bookmark list (as I'm guessing many people do, given the number of people using Pinboard via IFTTT), they won't be reporting that to you.
Man, I wanted to do this so badly on the original delicious.<p>I have some ways of identifying aggregate misbehavior if you want to catch this. Happy to help.
Confession time: I'm somewhat of an accomplice in this unspeakable evil.<p>I maintain the (unofficial but widely used) Pinboard API client library for PHP. Until recently, it only supported password authentication. Development had all but ground to a halt in the last couple of years, partly because the API itself hasn't changed at all since 2012, and partly because I didn't want to spend any more time on API v1 when API v2 might hit production anytime, but mostly because I just forgot.<p>As a result, web services written in PHP are probably more likely to use password auth with Pinboard than those written in other languages. Sorry, @idlewords!<p>But thanks to an enthusiastic contributor who appeared out of nowhere and chastised me for slacking off, the PHP client library has now gained most of the features that it had been missing for years, including token auth. Even better, the API allows you to get a user's token given his username and password, so you can easily convert your existing database to tokens without any user interaction.
Maybe sites like IFTTT are doing it because it's much easier to remember a username/password (assuming you don't use generated passwords) than an API token. A global third-party api token barely provides much more safety than giving up a random password to said third-parties. If you want to prevent one third-party app from continued access you have to go around to all the others and update the token (just like with a password).<p>Don't get me wrong, I'm in favor of removing user's passwords from third-parties (and blocking those who won't update). I'm just wondering why Pinboard hasn't built a proper OAuth system which would remedy all the above problems. It even mentions OAuth on the api docs:
"This token is intended as a stopgap measure to prevent third-party sites from having to store Pinboard credentials while the site moves to full Oauth support."
Wow, that's almost as bad as sites that ask for my credit card number. Of course, my CC number is like my name: public information. Unfortunately, the companies behind the card seem to think it's more like a password. While the law protects me from most liability for fraud, they still want to change my name, er account number, every time there's an issue. That requires me to re-enter it in various websites, inevitably at the least convenient time.<p>Thanks for helping drag the world into the future.
I think one of the problems with the API token is that it's a lot more cumbersome for the user right now than the old password-based flow. (If you don't happen to have your token around or work with it daily)<p>Right now to connect an API consumer, you have to:<p>1) Do the things on the consumer's site until you're prompted for the token<p>2) Open pinboard.in (presumely in a different tab)<p>3) Login to pinboard<p>4) Go to "settings"<p>5) Go to "password"<p>6) Copy API token<p>7) Switch back to consumer's site<p>8) Paste token<p>Steps 4 and 5 might be more difficult than they look: If people didn't use the token before or never had to change their password, they might not know how to get to settings > password. Or they might not know where to find the token at all.<p>I think you could make things a lot more convenient if API consumers could put a direct link to <a href="https://pinboard.in/settings/password" rel="nofollow">https://pinboard.in/settings/password</a> on their page. That way, the flow would look like this:<p>1) Do things on the API consumer's site until you're prompted for the token<p>2) Follow link to token page<p>3) Login to pinboard<p>4) Copy API token<p>5) Switch back to consumer's site (or click "back" twice)<p>6) Paste token<p>7) Profit!<p>Right now, this almost works, except that if you're not already logged into pinboard, the link will just take you back to the front page. So you'd have to change the login prompt so it remembered where you came from. That sounds like a pretty insignificant change, but I think it could make a difference.
Good for them. I don't understand why a service would require a 3rd party username and password for any reason if an API Key/Oauth solution existed.
Curious - Does anyone know the legality of providing a username and password and passing it through to another site that doesn't have an API/oAuth? Is it all based on the ToS of that site? It sounds like IFTTT does it / has done it. I'm really surprised by that. Isn't this a big no-no?