Live data from Hacker News

How not to write an API

ghost.teario.com

151–160 of 172 posts

Re: How not to write an API

#152
post #147

Raw password storage is more common than we like to believe. A simple way for webapps to communicate that raw passwords are not being stored would be convenient. A small 'NORAWPW' image in the footer perhaps. it would ease my worries, especially with cryptocurrency related webapps.

"Designed for IE" "Designed for Netscape" "Designed in Notepad"

No thanks!

Re: How not to write an API

#153

Earlier quoted context omitted.

Even if your api uses oAuth I don't see how can you prevent the client app to steal the password. At some point the user is going to have to give his password to someone. Can't the app ask the user for his password, keep it, and internally give it to oAuth to allow to use your api?

The user will enter their password on the provider's site via the phone browser. It relies on the user's trust of the system browser.

I meant for a native app and you being the provider. If you don't trust the client app even oAuth won't help you preventing the client app to know the user password.

Re: How not to write an API

#154
post #78
post #67

Earlier quoted context omitted.

You mean like Symfony, Laravel, etc? Frameworks that a lot of PHP developers use these days...

You dont need a framework to do PHP webdev, in every other languages,you do.That's my point, PHP IS a templating language,no Symfony,Zend or Laravel can change that. If i write "print" in Python it wont output the result back to HTTP like PHP does. Ruby or Java dont have <?ruby or <?java tags, you get my point.

With PHP, unlike other languages, you have not two but three options - you can either run it as a web server module (That's your "templating" opinion and the most common use of PHP), you can run it trough the Common Gateway Interface (where even in Python or Ruby print DOES outputs to the HTTP) and in the end you can roll out your own HTTP server. In the last option, just like the common use of Python and Ruby, you have full control of what's going on with your code and you decide what to send over the socket and what (if anything) to print on the console.

Re: How not to write an API

#155

Earlier quoted context omitted.

All the php hate I've seen over the years is because of one guy who doesn't know what he's doing? ;)

Oh yeah, I forgot, because of the low barrier of entry, PHP is the only language in the history of all programming languages where there are people who don't know what they are doing. Forgot that all Python, Ruby, etc devs are gods gift to programming and don't make mistakes. My good, your bad.

upvoting you despite your inability to take a bit of good-natured ribbing

Re: How not to write an API

#156
post #130

How should an app utilizing an API send the API key so it can't be hijacked with tcpdump?

You can't really avoid it. If the API key is hardcoded in the client, it's just a matter of time and patience until it's extracted. Never trust the client.

Re: How not to write an API

#157
post #130

How should an app utilizing an API send the API key so it can't be hijacked with tcpdump?

By using HTTPS/SSL. But the onus of that is on the API provider...

It also doesn't help that much - you can still look up the api key in the package, which isn't a whole lot harder. You could probably sign your own cert, tell your device to trust it, and MITM it, too.

Re: How not to write an API

#158

Earlier quoted context omitted.

Oh yeah, I forgot, because of the low barrier of entry, PHP is the only language in the history of all programming languages where there are people who don't know what they are doing. Forgot that all Python, Ruby, etc devs are gods gift to programming and don't make mistakes. My good, your bad.

upvoting you despite your inability to take a bit of good-natured ribbing

Sorry, just as a PHP developer who understands his language isn't perfect but is growing and fixing pains, it annoys me to see people who don't use or haven't used the language since PHP4 talk trash about it as if they've been a PHP developer for years and use it daily.

Rarely do you see PHP developers talking about the pitfalls of big frameworks and other languages.. For example XSS vulnerabilities that recently plagued Rails.

I too have upvoted both your replies to show no ill will. Beautiful day here in Chicago and I took a little time off to cruise the city before coming back and getting back to work. Really puts you in a good mood.

Re: How not to write an API

#159

Earlier quoted context omitted.

I don't care if this comes off as trolling, but here it is: as I read through this, I thought to myself, much like the author, "how appaling!" - then I saw the word "PHP" - and went "oh, well that means there's gonna be a bunch of people hating on a language because one developer doesn't know what he's doing and happens to be using that language".

All the php hate I've seen over the years is because of one guy who doesn't know what he's doing? ;)

...Rasmus Lerdorf?

Re: How not to write an API

#160
post #30

Earlier quoted context omitted.

I dont think you realize how common the WTFs in this situation are. If you are dealing with a reputable company, this is super super WTF. When you are looking at a small website/API someone made for fun or something....It can normally be badly broken in less than 2-3 minutes....and I'm not even that talented like some of the guys out there.

My day job is web developer and i sit in an IRC channel where roughly half the traffic is making fun of security issues of sites. Such a glorious combination of fuckups doesn't come about that often. I'm honestly more apalled that the passwords are in plaintext than that they expose them like that. I cannot say i am surprised though. A general amount of carelessness, undeserved self-confidence and ignorance is a give…

[deleted]
Post reply on HN