Last year I built the platform 'Tindex'. It was an index of Tinder profiles so people could search by name, gender and age.

We scraped the Tinder profiles through a Tinder API which was discontinued not long ago, but weird enough it was still intact and one of my friends who was also working on it found out how to get api keys (somewhere in network tab at Tinder Online).

Except name, gender and age we also got 3 distances so we could calculate each users' location, then save the location each 15 minutes and put the coordinates on a map so users of Tindex could easily see the current location of a specific Tinder user.

Fun note: we also got the Spotify data of each Tinder user, so we could actually know on which time and which location a user listened to a specific Spotify track.

Later on we started building it out: A chatbot which connected to Tinder so Tindex users could automatically send a pick up line to their new matches (Was kinda buggy, sometimes it sent 3 pick up lines at ones).

Right when we started building a revenue model we stopped the entire project because a friend of ours had found out that we basically violated almost all terms.

Was a great project, learned a lot from it and actually had me thinking twice or more about online dating platforms.

Below an image of the user overview design I prototyped. The data is mock-data.

Dear me,

We have noticed you uploaded files to a public github with your API keys in plaintext.

Please proceed to bang head against desk until you have learned your lesson.

Sincerely me.

!rant

This was over a year ago now, but my first PR at my current job was +6,249/-1,545,334 loc. Here is how that happened... When I joined the company and saw the code I was supposed to work on I kind of freaked out. The project was set up in the most ass-backward way with some sort of bootstrap boilerplate sample app thing with its own build process inside a subfolder of the main angular project. The angular app used all the CSS, fonts, icons, etc. from the boilerplate app and referenced the assets directly. If you needed to make changes to the CSS, fonts, icons, etc you would need to cd into the boilerplate app directory, make the changes, run a Gulp build that compiled things there, then cd back to the main directory and run Grunt build (thats right, both grunt and gulp) that then built the angular app and referenced the compiled assets inside the boilerplate directory. One simple CSS change would take 2 minutes to test at minimum.

I told them I needed at least a week to overhaul the app before I felt like I could do any real work. Here were the horrors I found along the way.

- All compiled (unminified) assets (both CSS and JS) were committed to git, including vendor code such as jQuery and Bootstrap.
- All bower components were committed to git (ALL their source code, documentation, etc, not just the one dist/minified JS file we referenced).
- The Grunt build was set up by someone who had no idea what they were doing. Every SINGLE file or dependency that needed to be copied to the build folder was listed one by one in a HUGE config.json file instead of using pattern matching like `assets/images/*`.
- All the example code from the boilerplate and multiple jQuery spaghetti sample apps from the boilerplate were committed to git, as well as ALL the documentation too. There was literally a `git clone` of the boilerplate repo inside a folder in the app.
- There were two separate copies of Bootstrap 3 being compiled from source. One inside the boilerplate folder and one at the angular app level. They were both included on the page, so literally every single CSS rule was overridden by the second copy of bootstrap. Oh, and because bootstrap source was included and commited and built from source, the actual bootstrap source files had been edited by developers to change styles (instead of overriding them) so there was no replacing it with an OOTB minified version.
- It is an angular app but there were multiple jQuery libraries included and relied upon and used for actual in-app functionality behavior. And, beyond that, even though angular includes many native ways to do XHR requests (using $resource or $http), there were numerous places in the app where there were `XMLHttpRequest`s intermixed with angular code.
- There was no live reloading for local development, meaning if I wanted to make one CSS change I had to stop my server, run a build, start again (about 2 minutes total). They seemed to think this was fine.
- All this monstrosity was handled by a single massive Gruntfile that was over 2000loc. When all my hacking and slashing was done, I reduced this to ~140loc.
- There were developer's (I use that term loosely) *PERSONAL AWS ACCESS KEYS* hardcoded into the source code (remember, this is a web end app, so this was in every user's browser) in order to do file uploads. Of course when I checked in AWS, those keys had full admin access to absolutely everything in AWS.
- The entire unminified AWS Javascript SDK was included on the page and not used or referenced (~1.5mb)
- There was no error handling or reporting. An API error would just result in nothing happening on the front end, so the user would usually just click and click again, re-triggering the same error. There was also no error reporting software installed (NewRelic, Rollbar, etc) so we had no idea when our users encountered errors on the front end. The previous developers would literally guide users who were experiencing issues through opening their console in dev tools and have them screenshot the error and send it to them.
- I could go on and on...

This is why you hire a real front-end engineer to build your web app instead of the cheapest contractors you can find from Ukraine.

GitHub: a marketplace for publicly available API keys

Storytime!

Manager: Hey fullstackchris, the maps widget on our app stopped working recently...

Dev: (Skeptical, little did he know) Sigh... probably didn't raise quota or something stupid... Logs on to google cloud console to check it out...

Google Dashboard: Your bill.... $5,197 (!!!!!!) Payment method declined (you think?!)

Dev: 😱 WTF!?!?!! (Calls managers) Uh, we have HUGE problem, charges for $5000+ in our google account, did you guys remove the quota limits or not see any limit reached warnings!?

Managers: Uh, we didn't even know that an API could cost money, besides, we never check that email account!

Dev: 🤦‍♂️ yeah obviously you get charged, especially when there have literally been millions of requests. Anyway, the bigger question is where or how our key got leaked. Somewhat started hammering one of the google APIs with one of our keys (Proceeds to hunt for usages of said API key in the codebase)

Dev: (sweating 😰) did I expose an API key somewhere? Man, I hope it's not my fault...

Terminal: grep results in, CMS codebase!

Dev: ah, what do we have here, app.config, seems fine.... wait, why did they expose it to a PUBLIC endpoint?!

Long story short:

The previous consulting goons put our Angular CMS JSON config on a publicly accessible endpoint.

WITH A GOOGLE MAPS API KEY.

JUST CHILLING IN PLAINTEXT.

Though I'm relieved it wasn't my fault, my faith in humanity is still somewhat diminished. 🤷‍♂️

Oh, and it's only Monday. 😎

Cheers!

I've had my share of incompetent coworkers. In order of appearance:

1. A full stack dev. This one guy never, and I mean NEVER uses relationships in their tables. No indexing, no keys, nada. Couple of months later he was baffled why his page took ten seconds to load.

2. The same dev as (1). Requirement was to create some sort of "theme" feature for a web app. Hacked it by putting !important all over the place.

3. The same dev again. He creates several functions that if the data exists returns a view, and if it doesn't, "echo '0'". No, not return 0 or return false or anything, but fucking echo. This was PHP. If posted a rant about this a few months ago.

4. Same dev, has no idea what clean code is. No, not just reusable functions, he doesn't even get indenting right. Some functions have 4 spaces, some 2 tabs, some 6 tabs! And this is inside the same function. God wait until he tries Python...

5. Same dev now suggests that he become the PM. GM approves (very small company). Assigns me to travel to a client since they needed "technical assistance about the API". Was actually there to lead a UAT session.

Intermezzo, that guy went from fullstack dev to PM to sales (yes, one who calls clients to offer products) to business development, to product analyst in the span of two years.

After a year and a half there, I quit.

6. New company, a "QA engineer" who also assumes the role as the product owner. Does absolutely no tests other than "functional tests" in which he NEVER produces any form of documentation. Not even a set of test cases. He goes by "intuition".

7. Same guy as (6), hands me requirements for a feature. By "hands me" I mean he did that verbally. No spec documents, no slack chat, no Trello card. I ended up writing it as a card in Trello. Fast forward to the due date, he flips out because that wasn't what he wanted. Showed him the card. He walked away, without thinking of a solution how this mess should be handled.

Despite all this, I really don't want him (6&7) to leave the company. The devs get really stressed out at this job and he does make a really good person to laugh with/at.

I realize I've ranted about this before, but...

Fuck APIs.

First the fact that external services can throw back 500 errors or timeouts when their maintainer did a drunk deploy (but you properly handled that using caching, workers, retry handlers, etc, right? RIGHT?)...

Then the fact that they all speak a variety of languages and dialects (Oh fuck why does that endpoint return a JSON object with int keys instead of a simple array... wait the params are separated with pipe characters? And the other endpoint uses SOAP? Fuck I need to write another wrapper class around the client...)

But the worst thing: It makes developers live in this happy imaginary universe where "malicious" is not a word.

"I found this cloud service which checks our code style" — hmm ok, they seem trustworthy. Hope they don't sell our code, but whatever.

"And look at this thing, it automatically makes database backups, just have to connect to it to DigitalOcean" — uhhh wait...

"And I just built this API client which sends these forms to be OCR processed" — Fuck... stop it... there are bank accounts numbers on those forms... Where's that API even located? What company?

* read their privacy policy *

"We can not guarantee the safety of your personal data, use at your own risk [...] we are located in Russia".

I fucking hate these millennial devs who literally fail to get their head out of the cloud.

Somehow they think it's easier to write all these NodeJS handlers and layers around some API, which probably just calls ImageMagick + Tesseract on the other side.

If I wasn't so fucking exhausted, I'd chop of their heads... but they're like hydra, you seal one privacy breach and another is waiting to be merged, these kids just keep spewing their crap into easy packages, they keep deploying shitty heroku apps... ugh.

😖

Never gonna happen:

* Port our API to graphql. Or even make it just vaguely rest-compliant. Or even just vaguely consistent.
* Migrate from mysql to postgres. Or any sane database.
* Switch codebase from PHP to... well, anything else.
* Teach coworkers to not commit passwords, API keys, etc.
* Teach coworkers to write serious commit messages instead of emoji spam
* Get a silent work environment.
* Get my office to serve better snacks than fermented quinoa spinach bars and raw goat milk kale smoothies
* Find an open source IDE with good framework magic support. Jetbrains, I'll give you my left testicle if you join the light side of the force.
* Buy 2x3 equally sized displays. I'm using 6, but they're various sizes/resolutions.
* Master Rust.
* Finish building my house. I completely replaced the roof, but still have to dig out a cellar (to hide my dead coworkers).
* Repair/replace the foundation of my house (I think Rust is easier)
* Get slim and muscular.

Realistically:

* Get a comfortable salary increase, focus more on platform infrastructure, data design, coaching
* Get fat(ter). Eating, sitting, gaming, coding and sleeping are my hobbies after all.
* Save up for the inevitable mental breakdown-induced retirement.

I had to open the desktop app to write this because I could never write a rant this long on the app.

This will be a well-informed rebuttal to the "arrays start at 1 in Lua" complaint. If you have ever said or thought that, I guarantee you will learn a lot from this rant and probably enjoy it quite a bit as well.

Just a tiny bit of background information on me: I have a very intimate understanding of Lua and its c API. I have used this language for years and love it dearly.

[START RANT]

"arrays start at 1 in Lua" is factually incorrect because Lua does not have arrays. From their documentation, section 11.1 ("Arrays"), "We implement arrays in Lua simply by indexing tables with integers."

From chapter 2 of the Lua docs, we know there are only 8 types of data in Lua: nil, boolean, number, string, userdata, function, thread, and table

The only unfamiliar thing here might be userdata. "A userdatum offers a raw memory area with no predefined operations in Lua" (section 26.1). Essentially, it's for the API to interact with Lua scripts. The point is, this isn't a fancy term for array.

The misinformation comes from the table type. Let's first explore, at a low level, what an array is. An array, in programming, is a collection of data items all in a line in memory (The OS may not actually put them in a line, but they act as if they are). In most syntaxes, you access an array element similar to:

array[index]

Let's look at c, so we have some solid reference. "array" would be the name of the array, but what it really does is keep track of the starting location in memory of the array. Memory in computers acts like a number. In a very basic sense, the first sector of your RAM is memory location (referred to as an address) 0. "array" would be, for example, address 543745. This is where your data starts. Arrays can only be made up of one type, this is so that each element in that array is EXACTLY the same size. So, this is how indexing an array works. If you know where your array starts, and you know how large each element is, you can find the 6th element by starting at the start of they array and adding 6 times the size of the data in that array.

Tables are incredibly different. The elements of a table are NOT in a line in memory; they're all over the place depending on when you created them (and a lot of other things). Therefore, an array-style index is useless, because you cannot apply the above formula. In the case of a table, you need to perform a lookup: search through all of the elements in the table to find the right one. In Lua, you can do:

a = {1, 5, 9};
a["hello_world"] = "whatever";

a is a table with the length of 4 (the 4th element is "hello_world" with value "whatever"), but a[4] is nil because even though there are 4 items in the table, it looks for something "named" 4, not the 4th element of the table.

This is the difference between indexing and lookups. But you may say,

"Algo! If I do this:

a = {"first", "second", "third"};
print(a[1]);

...then "first" appears in my console!"

Yes, that's correct, in terms of computer science. Lua, because it is a nice language, makes keys in tables optional by automatically giving them an integer value key. This starts at 1. Why? Lets look at that formula for arrays again:

Given array "arr", size of data type "sz", and index "i", find the desired element ("el"):

el = arr + (sz * i)

This NEEDS to start at 0 and not 1 because otherwise, "sz" would always be added to the start address of the array and the first element would ALWAYS be skipped. But in tables, this is not the case, because tables do not have a defined data type size, and this formula is never used. This is why actual arrays are incredibly performant no matter the size, and the larger a table gets, the slower it is.

That felt good to get off my chest. Yes, Lua could start the auto-key at 0, but that might confuse people into thinking tables are arrays... well, I guess there's no avoiding that either way.

So we had a dev on our team who was on a performance improvement plan, wasn't going to pass it, but decided to quit before it was over saving us 2 weeks.

I was ecstatic when he left (caused us hell). I knew updating his code wouldn't be great, but he was only here 6 months

"how bad could it be" - practiseSafeHex - moron, idiot, suicidal.

A little run down would be:

- Despite the fact that we use Angular 2+, one of his apps is Angular 1 ... Nobody on the team has ever used Angular 1.

- According to his package.json he seems to require both mongoDb and Cloudant (couchDb).

- Opened up a config file (in plaintext) to find all the API keys and tokens.

- Had to rename all the projects (micro services) because they are all following a different style of camelcase and it was upsetting my soul.

- All the projects have a "src" folder for ... you know ... the source code, except sometimes we've decided to not use it for you know, reasons.

- Indentation is a mess.

- He has ... its like ... ok I don't even know wtf that is suppose to be.

- Curly braces follow a different pattern depending on the file you open. Sometimes even what function you look at.

- The only comments, are ones that are not needed. For example 30+ lines of business logic and model manipulation ... no comment. But thank god we have a comment over `Fs.readFile(...)` saying /* Read the config file */. Praise Jesus for that one, would have taken me all week to figure that out.

Managers have been asking me how long the "clean up" will take. They've been pushing me towards doing as little as possible and just starting the new features on top of this ... this "code".

The answer will be ... no ... its getting deleted, any machine its ever been on is getting burned, and any mention of it will be grounds for death.

I think I will ship a free open-source messenger with end-to-end encryption soon.

With zero maintenance cost, it’ll be awesome to watch it grow and become popular or remain unknown and become an everlasting portfolio project.

So I created Heroku account with free NodeJS dyno ($0/mo), set up UptimeRobot for it to not fall asleep ($0/mo), plugged in MongoDB (around 700mb for free) and Redis for api rate limiting (30 mb of ram for free, enough if I’m going to purge the whole database each three seconds, and there’ll be only api hit counters), set up GitHub auto deployment.

So, backend will be in nodejs, cryptico will manage private/public keys stuff, express will be responsible for api, I also decided to plug in Helmet and Sqreen, just to be sure.

Actual data will be stored in mongo, rate limit counters – in redis.

Frontend will probably be implemented in React, hosted for free at GitHub pages. I also can attach a custom domain there, let’s see if I can attach it to Freenom garbage.

So, here we go, starting up modern nosql-nodejs-react application completely for free.

If it blasts off, I’m moving to Clojure + Cassandra for backend.

And the last thing. It’ll be end-to-end encrypted. That means if it blasts off, it will probably attract evil russian government. They’ll want me to give him keys. It’ll be impossible, you know. But they doesn’t accept that answer. So if I accidentally stop posting there, please tell my girl that I love her and I’m probably dead or captured

My colleagues broke down our AWS account by hard coding the AWS access API keys and pushing the same code to a public repository. This took down our system for nearly 3 days.

!rant
!!pride

I tried finding a gem that would give me a nice, simple diff between two hashes, and also report any missing keys between them. (In an effort to reduce the ridiculous number of update api calls sent out at work.)

I found a few gems that give way too complicated diffs, and they're all several hundred lines long. One of them even writes the diff out in freaking html with colors and everything. it's crazy. Several of the simpler ones don't even support nesting, and another only diffs strings. I found a few possibly-okay choices, but their output is crazy long, and they are none too short, either.

Also, only a few of them support missing keys (since hashes in Ruby return `nil` by default for non-defined keys), which would lead to false negatives.

So... I wrote my own.
It supports diffing anything with anything else, and recurses into anything enumerable. It also supports missing keys/indexes, mixed n-level nesting, missing branches, nil vs "nil" with obvious output, comparing mixed types, empty objects, etc. Returns a simple [a,b] diff array for simple objects, or for nested objects: a flat hash with full paths (like "[key][subkey][12][sub-subkey]") as top-level keys and the diff arrays as values. Tiny output. Took 36 lines and a little over an hour.

I'm pretty happy with myself. 😁

TL;DR age != competence

My boss is a fucking computer illiterate self taught programmer.

Don't get me wrong, he can do shit, pretty shitty but it gets done...

But the dude has 38 fucking years old and somehow still searches for keys on the fucking keyboard and struggles to touch type anything...

I sometimes crying the fuck out when I have to help him with something...

I'm having a mini fucking panic attack right now just thinking of it... Fuck

He is our "manager" but doesn't even have the fucking balls to confront his own subordinates when they need to be confronted... Everyone is aware of this and everyone is fucking around... And no one sees any consequences... I wonder why deadlines are always missed...

He is so passive that every fucking thing someone asks he goes and says it is OK...

I was studying same psychology about ignorance and I think he lacks the understanding that shit is hard to do...

We literary had a conversation the other day something like that:

Boss: so, what do you think? One call to the api for it to return all data or multiple calls to return smaller ones?

Me: well... It takes ~180ms just for latency to the server for one call, if you have 10 calls it will take 180*10ms, it is better if we have one call and cache it if necessary on the backend.

( he has no fucking clue wtf caching is, besides browser cache)

Boss: (looking confuse AS FUCK!!) Well, I don't get it... Maybe I'll test it later.

Me thinking: test how you dumb motherfucker? On you fucking workstation with no fucking latency?
There is no fucking test. I'm stating it. IT IS A FUCKING FACT!

Me: well, it takes that for the call to go to the api and come back , its simple math. 1 == 180, 10 == 1800.
Suit yourself.

Coolest thing I’ve built solo?

Damn, there’s been a lot of things over the years, but I guess the most used one I’ve made would be my voice activated tv remote - yes it’s real.

So in essence it’s a google home... yea I know spyware and all, but look it was free so I’m going to make use of it... err where was I, oh yea.

An IFTTT account which taps into the google assistant API and creates a webhook, although the authentication side of things is 0 to none, so had to put a api-key into the requests to at least have some layer of auth.

This webhook then hits a raspberry pi containing a PHP API to accept and authenticate the request in, digest this into KEY commands for the TV, and drops this into a Python script to connect to the TV over a web socket connection ( I found python more stable for this ) and sends the pre made key requests, it can even do multiple keys at a time... that was a pain.

So after all that, the end game becomes about a second from saying “hey google, change the tv channel to xxx”

This sick and twisted contraption is finished and the tv is my little bitch.

This has been built out to handle channels by name, number, volume up/down, sources switching to hdmi, tv, vga and a bunch of other things.

The things we do when we can’t find a tv remote for days....

Next up, getting it to launch Netflix app and going to a specified show / episode.. but may be to adventurous.

Vendor: We are very professional and follow best practices, we know what we are doing. You should trust us.

Also Vendor 5 mins later: DB passwords, API keys and SSH keys in repo. AWS Access Keys shared in screenshots in email.

Me: 😭

Thank God the week 233 rants are over - was getting sick of elitist internet losers.

The worst security bug I saw was when I first started work as a dev in Angular almost year ago. Despite the code being a couple of years old, the links to the data on firebase had 0 rules concerning user access, all data basically publicly available, the API keys were uploaded on GitHub, and even the auth guard didn't work. A proper mess that still gives me the night spooks to this day.

Not sure if it was 2016 or late 2015, but it's a fun story anyway (and if it's not you'll at least learn something from it).

Back at the time I was quite new to unit testing (weird how it has become second nature in a years time). I was writing some software that was supposed to send out some SMS to customers. Of course this had to be tested. However, it was a bit difficult to test (or so I thought) without actually receiving an SMS to know if it was sent. So I decided to use the live API key to make sure the sending of SMS was actually working correctly. I tried it a few times but didn't receive an SMS. So I kept working on it and running tests.

The testing setup I had at the time was just a continues loop that went through all tests to make sure it all still worked (I've moved to only checking on file changes now, but that is besides the point). Keep in mind I was still running these tests, in a loop, with the _live_ API key.

So the end of the working day arrives and I go home and sit in the train. All of the sudden I receive some test SMS. I was thinking "hey nice, it did work". Then I started receiving more. It soon turned out to be an alarmingly big amount of SMS. It stopped around 100, but don't think that was the end of it. Oh no. I had changed the number to send the SMS to from my own number to a different number (+31612345678 to be exact, which I found out later isn't an actual phone number. I really hope I was right about that). I was beginning to become nervous, but there wasn't much I could do.

The next day I returned to work and checked the API for sent SMS. Turns out I had sent a couple of thousand (I think between two and three thousand) SMS in a couple of hours. Most of them to the test number I had supplied.

This probably cost the company a couple of hundred euros. Luckily my colleagues and team leader all thought it was pretty funny, but did tell me not to do it again. And I haven't of course.

Lesson learned: don't use live API keys during testing (among other things :)).

So yeah that was probably my worst dev experience.

I've just seen the documentation of an api I have to communicate with, and facepalmed when I have seen that some actions return 404 on success. And more bizarre things... Just wanted to make it worse for me, didn't you?
Once at it. Why don't you glue spikes onto my keys?
Ffs

So at the old job, i needed support for an issue relating to Amazon S3. We used a third party Python plugin for sending files to our buckets, but had some pretty severe performance issues when trying a 2-way sync.
Naturally, I sought help on StackOverflow, and was asked to share my config. Without much thought, I pasted the config file.
Next comment made me aware that our API id and key was listed in this config (pretty rediculous to keep such private info in the same file as configuration, but oh well).
I edited my question and removed the keys, and did not think about the fact that revisions are stored.

Two weeks later, my boss asks me if I know why the Amazon bill is for 25.000$ when it used to be <100$ 😳

I've never been so scared in my life. Luckily, Amazon was nice enough to waive the entire fee, and I leaned a little about protecting vital information

A government website that I wanted to try and scrape data from to make a better app, I've actually found to be the pinnacle of a demonstration of what NOT to do...

Containing a JavaScript file that not only had got code copied 3 times (changed the tiniest bit on each) for what environment it's on, but has ALSO got the API keys for all 3 environments, AND the APIs they've made it call from there pass FULL SQL right in the query string...

What. The. Actual. Fuck?!

We have a new hire, and he doesn't know much so he is receptive when given feedback on better ways to handle a situation...Or at least, he appears that way. Until the next time and he didn't listen at all.

Today I'm working on the front end to match his API calls. I ask him about a list of options for one of the fields, as he didn't provide that info initially. No worries, there was a lot, easy to miss. He responds with a list of ~100 options, which he copied and pasted from, I'm assuming, their documentation. I tell him that's too many options to hard code, as there is an easy chance to have an error or for there to be one added or deleted, and ask if there is an API endpoint to get the list.

He then asks if I need the key and value, or just key. I tell him if he needs the value(human readable) then he can send me just the value, otherwise both. He says he just needs the key, so I let him know that I need both then, as the value is human readable. He says okay.

He proceeds to make the endpoint, I test it. Then I look at the code he wrote. Not only did he not send me both, he just sent the keys, but he hard coded all 100 keys as opposed to making the call to the external API.

Putting the API keys, secrets and passwords in the code and pushing it to git.

Stupid stupid stupid API that returns a 204 on failed validations.

Informative docs? Hell no! Here's a few hundred long-ass field names that you need to pass as a JSON.

Doesn't work huh? Yeah, you're structure's all wrong. Some of these are grouped in vaguely named keys like "Wholesale".

Oh you need those as well? Yeah, you can see the whole structure if you try to GET an object.

Oh you need an ID to GET an object? Yeah you can just go ahead and create as many as you want. This is just a sandbox API, it's cool.

Oh that's not the point? Ahh you need the structure to be able to create one! *haha* Right, I'll get back to you on that.

* Email correspondence over 2 weeks time. I have still yet to be able to make a an actual successful request. The fucking 204 doesn't count if it doesn't actually create the resource.

Fucking fucky fuckity fuck fuck fuck.

I swear to god if I ever meet this guy in person, I will probably buy him coffee or beer and have a long talk about how to build proper REST APIs.

Because I'm nice like that.

FUCKING HELL.

It's already enough that this FUCKING API I have to work with is a mess of JSON and XML responses mixed together.
With mixed german and english keys and attributes all sprinkled over it.
And API access locked to Austria only for some reason.

And then they even manage to fuck up the little bit of JSON they use.

It's just a fucking array of strings (where one could easily use integers).

They can stick this fucking steaming pile of shit that they call API up their PHP infested assholes.

I hate web development sometimes.

When your client sends a cropped screenshot of the API keys and you spend half an hour typing it out multiple times trying to match it and failing, then another 30min trying to explain the simple process of copying and pasting text.

You can send a cropped screenshot but not use Ctrl-C Ctrl-V or right-click copy right-click paste.

How the hell some devs are releasing to production before passing to QA, Alpha testing, staging at least handle all type of errors and hide your API Keys.

-Rant-
How do you (not) secure your Rest based web service?
1. Chain it to shady organic authentication system built by a hoard of monkeys high on Tequila.
2. have secret keys that get copy pasted into config flat files, and index them on your code search engine.
3. make the onboarding extremely platform specific that you need 500 environment variables, 50 scripts, 5 fancy device presses and a tap dance to make a GET call to the service.
4. fish through 500 rotating log files that the authentication system generates for each API call made.
5. Leave traces all over the host so if you have to start over, you should sudo rm -rf / and set fire to your computer.

Wow or wtf to these banks API. was integrating an API for a service which accept JSON input.
Okay fair enough, that would be fine
Spent an hour writing code(purescript) most of time spent was on writing Types based on the API doc. after that okay let me test the API it failed.
I was what happened? So tested the API from postman with the payload from the doc, it worked. What how?
used a JSON diff to compare the payload from postman and the log. Looked same to me after spending few hours checking what is wrong with it .trying changing value to pasting the body of the log request in postman and trying everything failed.
Later went to the original working payload provided by them and changing the order. It started throwing error. I was like wait what?
It must be only on there UAT. created a payload with production creds and hoping to our production server (they have IP whitelist) ran the curl with proper payload as expected it worked. Later for same payload changed the order or one key and tried it failed.
Just why????
I don't want to create a JSON with keys on specific order. Also it's not even sorted order.

Sometimes I commit fixes for issues on my crypto exchange api repos without testing them and tell the issue author to test it themselves because "I don't have api keys for the respective api" to test it.

I'm fully registered on every exchange from here to Japan. 🙄

At my internship we as interns had to work on a CRM system. We used the google api since the company is using google accounts already. Before the project is done my internship is over but I could start my traineeship 4 weeks later.

Together with another old intern/now trainee I spent 4 hours on debugging the login system the first day we came back. Turns out somebody thought we didnt need the application keys anymore and thus deleted the application from the google developer console....

There’s got to be a record to how quickly I’ve fucked something up. Most recent record? Twitter API, accidentally archived a glitch project that had my keys in it. 30 minutes.

*flashbacks to all the times i've accidentally pushed api keys to master*

To me this is one of the most interesting topics. I always dream about creating the perfect programming class (not aimed at absolute beginners though, in the end there should be some usable software artifact), because I had to teach myself at least half of the skills I need everyday.

The goal of the class, which has at least to be a semester long, is to be able to create industry-ready software projects with a distributed architecture (i.e. client-server).

The important thing is to have a central theme over the whole class. Which means you should go through the software lifecycle at least once.

Let's say the class consists of 10 Units à ~3 hours (with breaks ofc) and takes place once a week, because that is the absolute minimum time to enable the students to do their homework.

1. Project setup, explanation of the whole toolchain. Init repositories, create SSH keys for github/bitbucket, git crash course (provide a cheat sheet).
Create a hello world web app with $framework. Run the web server, let the students poke around with it. Let them push their projects to their repositories.
The remainder of the lesson is for Q&A, technical problems and so on.

Homework: Read the docs of $framework. Do some commits, just alter the HTML & CSS a bit, give them your personal touch.
For the homework, provide a $chat channel/forum/mailing list or whatever for questions where not only the the teacher should help, but also the students help each other.

2. Setup of CI/Build automation. This is one of the hardest parts for the teacher/uni because the university must provide the necessary hardware for it, which costs money. But the students faces when they see that a push to master automatically triggers a build and deploys it to the right place where they can reach it from the web is priceless.
This is one recurring point over the whole course, as there will be more software artifacts beside the web app, which need to be added to the build process. I do not want to go deeper here, whether you use Jenkins, or Travis or whatev and Ansible or Puppet or whatev for automation. You probably have some docker container set up for this, because this is a very tedious task for initial setup, probably way out of proportion. But in the end there needs to be a running web service for every student which they can reach over a personal URL. Depending on the students interest on the topic it may be also better to setup this already before the first class starts and only introduce them to all the concepts in a theory block and do some more coding in the second half.

Homework: Use $framework to extend your web app. Make it a bit more user interactive with buttons, forms or the like. As we still have no backend here, you can output to alert or something.

3. Create a minimal backend with $backendFramework. Only to have something which speaks with the frontend so you can create API calls going back and forth. Also create a DB, relational or not. Discuss DB schema/model and answer student questions.

Homework: Create a form which gets transformed into JSON and sent to the backend, backend stores the user information in the DB and should also provide a query to view the entry.

4. Introduce mobile apps. As it would probably too much to introduce them both to iOS and Android, something like React Native (or whatever the most popular platform-agnostic framework is then) may come in handy. Do the same as with the minimal web app and add the build artifacts to CI. Also talk about getting software to the app/play store (a common question) and signing apps.

Homework: Use the view API call from the backend to show the data on the mobile. Play around with the mobile project to display it in a nice way.

5. Introduction to refactoring (yes, really), if we are really talking about JS here, mention things like typescript, flow, elm, reason and everything with types which compiles to JS. Types make it so much easier to refactor growing codebases and imho everybody should use it.
Flowtype would make it probably easier to get gradually introduced in the already existing codebase (and it plays nice with react native) but I want to be abstract here, so that is just a suggestion (and 100% typed languages such as ELM or Reason have so much nicer errors).
Also discuss other helpful tools like linters, formatters.

Homework: Introduce types to all your API calls and some important functions.

6. Introduction to (unit) tests. Similar as above.
Homework: Write a unit test for your form.

(TBC)

Project with partner company, during the meeting I asked them how can we secure the communication between two services. I suggested api keys, tokens. They were like nope, no need. But I asked them for their IPs to do whitelisting on our side in Nginx.

But their side, nah not even whitelisting, no tokens, no validations. If one has address, can send anything from anywhere.

How hard would it be to do at least, AT LEAST simple token validation. And they are using the very old IIS server. I think for them as long as data flows in as expected, it is fine.

;-) this is "find a store" page of an International ISP.
they cannot even handle their google api keys.
how they can handle my data.

Once upon a time we had to integrate our backend with the billing service of another company. They sent us a Swagger API Description, describing the payload they will send to us. Everything was ok, and we implemented it.

We told them our background was ready to run some tests, but they got some error. After some quick debug i asked for the actual payload they just sent to me.

The payload had different field types, different field names and non-nullable keys was explicitly coming as null.

THEY DIDN'T FOLLOW THEIR OWN SPECIFICATIONS!

When the buisness account manager asks you why the module isnt done, and doesnt understand that you cant test anything until he actually sets up the account, and gets you the development keys for the api you are supposed to integrate.

Don’t commit your terraform state to github please, especially if it contains over 20 API keys for various services, and database master passwords.

Not speaking from experience of having to do some frantic rebasing of someones PR *eye twitch*

Just removed an API key from one of my GitHub repos (yeah I know API keys don't belong there) and at the moment i pushed the corrected file, I got an email from GitGuardian that it discovered a key in my Repo although i deleted it. Anyone else experienced something similar?

The positive side of EnvVars...
So a couple of weeks ago I moved all api keys and db passwords to environmental variables on the server so that I didn't have to keep worrying if I'm live in my test environment.

Earlier I shat myself after an apt-get upgrade broke php and apache somehow decided it's a great idea to serve all .php files as plain text. I was super relieved to find no confidential information (apart from logic) was made public.

It feels kinda awkward to have a Facebook account only to request API keys, do not accept friend requests to not invade their wall with useless posts from apps you develop and be considered rude because of this! u.u

How do you guys prefer to hide the API keys you use in your (native) Android apps?

I'm an Android noob and the app I'm building uses some NLP services which are accessed through a key. I searched around and found a few techniques (obfuscation, serverside storage, etc.), just wanted to know what you folks recommend.

"And would any of ya folks be kind enough to write down a small script doin that?"

Yeah, sure... No! That would require us to make testing API keys, write connection logic, test it, debug it, test it again, et.c.

Just because it's simple doesn't mean it takes 0-time. I've learned that by listening to an idea of yours previously and sent months being your personal closed-source programmer for a huge-ass project you later abandoned before production. Go away.

My friend said I should make some of my old dead projects public (after removing passwords or api keys) even if they were badly done at least to show growth and development to recruiters.

I don't know though, I had a ton of random projects most I didn't bother with good practices assuming I'd be the only person to see the code, or telling myself I'd fix it later though eventually letting the project die for various reasons

should I really make bad projects public or should I keep them private waiting for a slim possibility of me reviving them.

I've been working for so long with API integrations and one part of that is security. We perform ssl key exchanges for 2-way verification and a large percent of those partners provides me with their own pkcs12 file which contains their private and public keys! What's the sense of the exchange!? I think they just implement it just to boast that they "know" how ssl works,

I've been freelancing lately with an agency to develop an android app for their client and at the same time another person is developing the website .

The story begins when I first contacted the web dev to give me access to the database (because he started before me ).It turns out that this guy purchased an almost ready cms template with a shitty data structure that has no relations between object .This database has no primary keys , no foreign keys , no indexes ... no nothing . Adding to that the web dev refused that I rewrite a new data structure claiming that he has done a good progress on the website .
Forward couple of weeks , I managed to create the api and develop an alpha for the app and sent it to the agency manager .
This bastard told me that the website and design have changed and the app shouldn't be like that .He told me to contact the other bastard the web dev to seen what the changes are . I'm waiting for the response about the new updates and I'm praying that they'll be just minor colors updates or something not a whole concept update .

My problem here is I'm stuck with this fucking agency cuz they paid half of the payment when I started .

Damn I must learn to say no to people .

So me and a couple of my teammates were developing a website for artists where all the things related to artists such as artworks, events, geolocation info etc. happen to live.
2 months down the line, the client comes up with another team who is supposed to develop iOS and Android apps to give the users the ability to leverage this data.
Now this team is so annoying that they want the API according to the specifications they provide. That's really weird. API should be generic, right?

But no, this doesn't end here, the PM of mobile app team comes up with a specification document for the API and what does it contain, a few endpoints which go as below:-
/home - To bring all the home screen data
/events - To bring all the event screen data. But here is a twist, on Event screen, they have defined different sections for Upcoming Events, Workshops, Talks etc. And for each event type they don't want a filtered API but just this single endpoint which will contain all event types data in their own JSON keys.
FML
:/

Guys, can you recommend a free cloud server that can be used as proxy server?

I wanna keep my api keys safe.

Google: secure api keys in cordova

Results says I cant or I can but my brain dont understand the method

I'm banging my head against the wall aaaaaarghh

Hey ranters, I want to setup a centralised auth backend that assigns multiple logins/API keys to a single user account which is managed through a Frontend application.

Background is we use multiple services each with their own login system and not all support a unified login/auth method for their API.

My approach is to setup a simple API/Auth backend that stores the users credentials plus multiple API-Keys of other services or their logins. When auth is successful the Frontend app may receive the associated credentials for the other backends to call their respective API. So the user can login once but the Frontend may access all backend services without the user noticing that their are other auths.

This should be a really general problem today. I'm really just diving into the topic of auth and Frontend, so I hope to get some guidence/overview from you. My questions are:

- Is my approach totally stupid?
- Are there good frameworks you'd recommend for such a setup?
- Is there a best practice which I've overseen so far?
- Resources you think are a must-read?
- Any other recommendations regarding security here?

So, what do you ranters think?

Commons sense/ best practice:

Is It ok ti initialize (angular) variabile as {id:" ", name:" ", ..} to avoid errors in the browser console such as "can't get ID of undefined"?

My concern is code readability and debugging, is not ok for the ones looking at the browser console to have such useless errors, on the other side you have to initialize some variables with object that have a lot of keys(id name ecc...) Whith empty fields...useless.

The apps work both cases, whit or whitouth initialization.
By the way we are getting such data by api calls later on.

I wonder how Saas companies like Zapier, Zendesk, etc...build a lot of common 3rd party integrations that perform the same set of tasks. I mean, do they just brute force in building those market place integrations or do they have an architecture where everything just works if the API keys are configured?

Eg: github, gitlab, Jira apis kind of do the same set of tasks but their APIs are different in structure. Is there a normalisation technique behind the scenes or they just build the same stuff 3 times.

Freaking hell, why google fucking sign in not working after the app is on google play, I have tried everything, run the release app on device and everything works, I thought they are using the bundles to generate and sign the apks so learned everything about fucking bundling and generated app bundles and signed it and generated .apks file locally “I already used the release key not debug key” double checked Auth api keys and installed on device and fucking everything works on the device except if I upload to google play then download to device the middle finger is waiting and google sign in not fucking working, I moved on and attached the app to Logcat and after a lot of digging I saw the fucking error 12501, I went to sleep after seeing this fucking error number. I’m fucking traveling now.

When there are multiple third party services getting used in your spring boot application. How do you manage their API creds.
Like I use Aws Secret Manager for the keys and different account level info. But after fetching in the application in runtime should we create classes to hold such info or just class variables are enough?
I'm more curious about the coding standard practices of different developers in the globe.

I have the following scenario with a proposed solution, can anyone please confirm it is a secure choice:
- We have critical API keys that we do not want to ship with the app because de-compiling will give access to those keys, and the request is done before the user logs in, we are dealing with guests

Solution:
- Add a Lambda function which accepts requests from the app and returns the API keys
- Lambda will accept the following:
1. Android app signing key sha1
2. iOS signing certificate sha1
- If lambda was able to validate them API keys are sent back.

My concerns:
- Can an attacker read the request from the original (non-tampered) apk and see what the actual sha1 value is on his local network?
- If the answer to the question above is yes, what is the recommended way to validate that the request received is actually from the app that we shipped and not from curl/postman/script/modified version of the app

I have seen references to API keys in several places. I have setup a few for various web services. However, I don't have a firm understanding of how they are protected (or not protected) from being copied and used by apps other than my own. I read a quick blurb from Google that said to use regular authentication over API keys due to them being able to be copied.

So my questions are: Are API keys just a bad way to subscribe services? Is there a way to protect them from being discovered? Maybe the app logs into a auth point for your services and is served the key to use with other services? But this key could still be gleaned from memory. Are API keys going to go away maybe in deference to things like oauth?