Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "token"
Fuck the memes.
Fuck the framework battles.
Fuck the language battles.
Fuck the titles.
Anybody who has been in this field long enough knows that it doesn't matter if your linus fucking torvalds, there is no human who has lived or ever will live that simultaneously understands, knows, and remembers how to implement, in multiple languages, the following:
- jest mocks for complex React components (partial mocks, full mocks, no mocks at all!)
- token cancellation for asynchronous Tasks in C#
- fullstack CRUD, REST, and websocket communication (throw in gRPC for bonus points)
- database query optimization, seeding, and design
- nginx routing, https redirection
- build automation with full test coverage and environment consideration
- docker container versioning, restoration, and cleanup
- internationalization on both the front AND backends
- secret storage, security audits
- package management, maintenence, and deprecation reviews
- integrating with dozens of APIs
- fucking how to center a div
and that's a _comically_ incomplete list; barely scratches the surface of the full range of what a dev can encounter in a given day of writing software
have many of us probably done one or even all of these at different times? surely.
but does that mean we are supposed to draw that up at a moment's notice some cookie-cutter solution like a fucking robot and spit out an answer on a fax sheet?
recruiters, if you read this site (perhaps only the good ones do anyway so its wasted oxygen), just know that whoever you hire its literally the luck of the draw of how well they perform during the interview. sure, perhaps some perform better, but you can never know how good someone is until they literally start working at your org, so... have fun with that.
Oh and I almost forgot, again for you recruiters, on top of that list which you probably won't ever understand for the entirety of your lives, you can also add writing documentation, backup scripts, and orchestrating / administrating fucking JIRA or actually any somewhat technical dashboard like a CMS or website, because once again, the devs are the only truly competent ones - and i don't even mean in a technical sense, i mean in a HUMAN sense of GETTING SHIT DONE IN GENERAL.
There's literally 2 types of people in the world: those who sit around drawing flow charts and talking on the phone all day, and those WHO LITERALLY FUCKING BUILD THE WORLD
why don't i just run the whole fucking company at this point? you guys are "celebrating" that you made literally $5 dollars from a single customer and i'm just sitting here coding 12 hours a day like all is fine and well
i'm so ANGRY its always the same no matter where i go, non-technical people have just no clue, even when you implore them how long things take, they just nod and smile and say "we'll do it the MVP way". sure, fine, you can do that like 2 or 3 times, but not for 6 fucking months until you have a stack of "MVPs" that come toppling down like the garbage they are.
How do expect to keep the "momentum" of your customers and sales (I hope you can hear the hatred of each of these market words as I type them) if the entire system is glued together with ducktape because YOU wanted to expedite the feature by doing it the EASY way instead of the RIGHT way. god, just forget it, nobody is going to listen anyway, its like the 5th time a row in my life
we NEED tests!
we NEED to know our code coverage!
we NEED to design our system to handle large amounts of traffic!
we NEED detailed logging!
we NEED to start building an exception database!
BILBO BAGGINS! I'm not trying to hurt you! I'm trying to help you!
Don't really know what this rant was, I'm just raging and all over the place at the universe. I'm going to bed.20
Hope you survived the Monday;)
As I promised, I’d like to post my comic series “Destory” here regularly.
A story about two devs and their funny but serious project, on the hype technology - the blockchain.6
Hey here we go:)
My first comic series - “DevStory”
A story of two devs aiming at changing the world’s impact about cryptos by their own token project.
Bugs, cheap scammers, money, flying unicorns and a lot of laughs!
Follow up to: https://devrant.com/rants/5047721/....
1- The attacker just copy pasted its JWT session token and jammed requests on the buy gift cards route
2- The endpoint returns the gift card to continue the payment process, but the gift card is already valid
3- Clients wants only to force passwords to have strong combinations
4- Talk about a FIREWALL? Only next month
5- Reduce the token expiration from 3 HOURS to 10 minutes? Implement strong passwords first
6- And then start using refresh tokens
BONUS: Clearly someone from inside that worked for them, the API and database password are the same for years. And the route isn't used directly by the application, although it exists and has rules that the attacker kows. And multiple accounts from legit users are being used, so the person clearly has access to some internal shit7
To everyone who’s enjoying / doesn’t but is going to enjoy ( ̀⌄ ́) the DevStory:
here we go, with the third episode.
Leave a comment below and tell me your “dev stories” :)11
How is the shopify developer experience actually so bad.
Shopify Buy JS docs suck
Product ID's are inconsistent
Token management is not built into GUI2
> * npm login *
> puts everything right, uses token because of OTP
> npm login fails: incorrect user or password
you know what, fuck you5
Sometimes while working I find a subproblem that is isolated from the original problem domain, for example token renewal in an RTR authentication system. I take note of what I've been working on, clear my head of the broader problem write an exact specification of the subproblem. Then I code to that specification. The result is usually a self-contained open-source module which continues to improve my pace of work for years to come.
Me: Hey I haven't used these repos/tokens/files in a while, let's remove them to clear up some space
Day later, a colleague: Hey Alex, could you update this repo/token/file?
EVERY FUCKING TIME1
So i wanna try explain the concept of JWT to a 5(+55) year old, and also to myself who is noob at web stuff. please tell me if this is a correct analogy, because i am myself confuse regarding how its secure?
So A wants B, a blind jeweller, to keep his super valuable notebook page with bank passwords safe. B says "give me your sheet and 5 nickels". (Assume that every nickel is always 1gm, made up of pure iron . Assume these statements to be true and world-known )
B takes A's nickels, melts them, adds 20gm more iron, adds 25gm copper, adds 25gm aluminum and then adds 25gm carbon dioxide and makes a mixture that is impossible to revert , but will automatically disintegrate after 24 hours due to CO2 (again, pure true statement, but this formula is only known to B) .
He makes 2 exact copies of keys from the 100 gm mixture, gives one to A and says
("Anyone can either give me 5 nickels of same name, markings, and year and i will give them back this secret sheet. or they give me the same key fo next 24 hours,and i will still give them back the sheets. after 24 hours, this key will also not work. I will even keep this on public display that i make keys using the materials I just showed, and then also no one would be able to create he exact same replica because they don't know how much percentage of each material went into the mixture"
So is this true? I have heard my friend boldly claim that they don't store user passwords as plaintext or even encoded text but rather doing this :
user password + company's private key --->[public domain encryption algorithm] = irreversible public key which is saved against user profile as "password"
public key + other info + time bound expiring logic ---->[public domain JWT encrypted token maker algorithm] = reversible JWTToken which is sent back to user
if user sends back token, then
token --> [JWT decoder] = public key + other info
if public key matches the stored public key , then user is a real user and should be given data
if user sends back the original password, then
user password + company's private key --->[public domain encryption algorithm] = irreversible public key .
again if public key matches the stored public key, then user will again receive access?
So this means all the time we are transmitting a lightly jumbled up version of public key, which is itself a hard, almost irreversible jumbled up version of our passwords that can only be unjumbled via a private key (or jewellers mixture ratios) that companies hold dearly ?5
There's no official integration (package) for JWT in Java Spring?
I am new to Java Spring and want to create a simple RESTful server with JWT auth. Checked many tutorials, all of them involved creating your own JWT middleware to retrieve JWT token from incoming request and validate it using some 3rd party JWT library like jwtk/jjwt.
I am surprised this is not as simple as including a Spring JWT package and it would work out of box. I used to write a similar site using Python/Django, and for that adding JWT support is quite simple as adding "xxx.middleware.JWTAuthMiddleware".1