Details
-
AboutTaught myself the best language for the job - am terrible at all of them
-
SkillsPython, Powershell, JS, Dart
-
LocationNew Zealand
Joined devRant on 3/15/2017
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
#Suphle Rant 9: a tsunami on authenticators
I was approaching the finish line, slowly but surely. I had a rare ecstatic day after finding a long forgotten netlify app where I'd linked docs deployment to the repository. I didn't realise it was weighing down on me, the thought of how to do that. I just corrected some deprecated settings and saw the 93% finished work online. Everything suddenly made me happier that day
With half an appendix chapter to go, I decided to review an important class I stole from my old company for clues when I need to illustrate something involved using a semblance of a real world example (in the appendix, not abstract foo-bar passable for the docs)
It turns out, I hadn't implemented a functionality for restricting access to resources to only verified accounts. It just hasn't been required in the scheme of things. No matter, should be a piece of cake. I create a new middleware and it's done before I get to 50 lines. Then I try to update the documentation but to my surprise, user verification status turns out to be a subset of authentication locking. Instead of duplicating bindings for both authentication and verification, dev might as well use one middleware that checks for both and throws exceptions where appropriate.
BUT!
These aspects of the framework aren't middleware, at all. Call it poor design but I didn't envisage a situation where the indicators (authentication, path based authorisation and a 3rd one I don't recall), would perform behaviour deviating from the default. They were directly connected to their handlers and executed after within the final middleware. So there's no way to replace that default authentication scheme with one that additionally checks for verification status.
Whew
You aren't going to believe this. It may seem like I'm not serious and will never finish. I shut my system down for that day, even unsure how those indicators now have to refactored to work as middleware, their binding and detachment, considering route collections are composed down a trie
I'm mysteriously stronger the following day, draw up designs, draft a bunch of notes, roll my sleeves, and the tsunami began. Was surprisingly able to get most of previous middleware tests passing again before bed, with the exception of reshuffled classes. So I guess we can be optimistic that those other indicators won't cause more suffering or take us additional days off course
2 -
November 2022
*Wife*: What do you want for x-mas? A new phone maybe? Yours has lived through a lot already - perhaps it's time for an upgrade?
*I*: Naah, thanks. My trusty S7 still works incredibly well. I also have all those 2FAs set up there and stuff I'm too lazy to transfer over to a new device.
*Parents*: What do you want for–//–
*I*: Naah, thanks. My tr–//–
*in-laws*: What do you want for–//–
*I*: Naah, thanks. My tr–//–
*Siblings*: What do you want for–//–
*I*: Naah, thanks. My tr–//–
January 2023:
*My phone*:
5 -
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.
51
