I'll give an example. At my previous company there was a program where you basically select a start date, select an end date, select the system and press a button and it reaches out to a database and pulls all the data following that matches those parameters. The horrors of this were 1. The queries were hard coded.

They were stored in a configuration file, in xml format.
The queries were not 1 entry. It was 4, a start, the part between start date and end date, the part between end date and system and then the end part. All of these were then concatenated in the program intermixed with variables.
This was then sent to the server as pure sql, no orm.
Here's my favorite part. You obviously don't want anyone modifying the configuration file so they encrypted it. Now I know what you're thinking at some point you probably will need to modify or add to the configuration so you store an unencrypted version in a secure location. Nope! The program had the ability to encrypt and decrypt but there were no visible buttons to access those functions. The program was written in winforms. You had to open the program in visual studio, manually expand the size of the window(locked size in regular use) and that shows the buttons. Now run the program in debug. Press the decrypt button. DO NOT EXIT THE PROGRAM! Edit the file in a text editor. Save file. Press the encrypt button. Copy the encrypted file to any other location on your computer. Close the program. Manually email the encrypted file to anybody using the file.

you are viewing a single comment's thread
view the rest of the comments

[–] CaptDust@sh.itjust.works 60 points 2 days ago* (last edited 1 day ago) (3 children)

I've had legacy systems that would encrypt user passwords, but also save the password confirmation field in plain text. There was a multitenent application that would allow front end clients to query across any table for any tenant, if you knew how to change a header. Oh and an API I discovered that would validate using "contains" for a pre-shared secret key. Basically if the secret key was "azh+37ukg", you could send any single individual character like "z" and it would accept the request.

Shits focked out here, mate.

[–] scrubbles@poptalk.scrubbles.tech 38 points 2 days ago (4 children)

Rules I've learned from software engineering for almost 2 decades.

Never roll your own ORM
Never roll your own Auth

No matter what you think, someone else did it better. Trying to do either of those outside of a hobby environment is pure hubris. "But I can do it better" - no you fucking can't. I have wasted much much more time debugging shitty "home grown" ORM solutions that clearly some dev just was bored and did than I have spent figuring out the quirks of whatever one I'm using. Same goes for auth. Just learn it.

[–] TootSweet@lemmy.world 16 points 2 days ago* (last edited 2 days ago) (1 children)

Never roll your own ORM

I've done this. Probably 10 years ago. Even today, I maintain the same application that has the ORM in it that I designed. If I could go back in time and do something else, I'd do the same thing again. Honest to god. For my use case, I feel it was warranted. It was risky, but it worked out surprisingly well.

[–] Clent@lemmy.dbzer0.com 3 points 1 day ago (1 children)

If I could go back in time and do something else, I'd do the same thing again.

So many questions here. What language? What's the database? How many years of experience do you have in industry?

We are the worse evaluators of our own code, some of us are down right terrible but most people regret less significant code choices in a matter of months. The fact that you still think it is good 10 years later is a massive red flag.

[–] TootSweet@lemmy.world 5 points 1 day ago

Java, Postgres mostly but also LDAP and random in-house-written RESTful services, almost 20 years.

The objects we store in the Postgres database are very "hierarchical" in nature, with one top-level object and lots of child/grandchild/great-grandchild objects. (We asked for a Mongo database but the infra team at the time said "make do with Postgres.)
As I mentioned, some of that hierarchy is in LDAP or RESTful services, not in Postgres, so we needed something capable of dealing with multiple storage backends that would stitch the objects together as necessary. So the "ORM" needed to have backends for multiple backend systems.
We knew clients would need a vast number of different queries. So we made a RESTful endpoint that gave the full power of the ORM to (authorized) clients. If they needed different data, we'd be like "change your query like this" and they didn't have to wait on us.
Early in the project, we consciously designed an extensible JSON representation of our hierarchical objects. That is what's returned from the aforementioned RESTful endpoint.
However, we also created a "shortcuts" system to allow us to "balance" how much of the logic lived on the server vs in the client. (It can mix and match. Like "apply this shortcut, but also filter this way and paginate" or whatever.)
We made the API of the ORM such that it could both be used to query from the database/LDAP/RESTful systems, or be used as a client SDK for the aforementioned RESTful query endpoint that the application exposed.
It's both "more than an ORM" (querying from non-database sort of backends) and not fully an ORM (read only, doesn't handle schema evolution.) But it's fair to say it's more "an ORM" than "not an ORM".
The implementation of the Postgres backend part of it is heavily inspired by Django's ORM.

We couldn't have pressed Hibernate into this use case. It doesn't really deal with hierarchical data and sure as hell doesn't know how to query from LDAP. I don't know that anything existed at the time (nor am I sure anything exists now) that would fulfill our use case.

And the alternative to what we built was a massive, unmaintainable DAO with ridiculous numbers of individual queries in it that would have to be modified or added to endlessly every time someone needed to filter a bit differently or whatever.

[–] Pieisawesome@lemmy.dbzer0.com 15 points 2 days ago (1 children)

The SVP over my org keeps wanting to design his own RBAC/Auth/IAM system.

We have entra, auth0, and keycloak.

The reason he wants it is he doesn’t want secrets to setup auth. Like that’s how it (mostly) works, sunshine.

[–] scrubbles@poptalk.scrubbles.tech 16 points 2 days ago

The reason he wants it is he doesn’t want secrets to setup auth

Yes I'd like auth without the auth please

[–] chocrates@piefed.world 6 points 2 days ago

I never fuck with auth. If I can throw it up the stack I'll do it as much as I can. When I can't I find an open source solution and Im sure I still misconfigure it

[–] olafurp@lemmy.world 2 points 1 day ago

I kinda rolled my own ORM, it was just a glorified class to SQL parameter converter that is then passed onto some SQL code. Then there was a thingy that marshals the result. Using table value functions in SQL standardises the result so any select * just works. It was around 50-100 lines total.

[–] vrek@programming.dev 6 points 2 days ago (1 children)

I have to ask, if it's only contains wouldn't you get a ton of collisions?

Expecting an apartment manager to know what a api header was nevermind how to change it is probably not likely. Security hole to be sure though.

[–] CaptDust@sh.itjust.works 11 points 2 days ago* (last edited 2 days ago) (1 children)

The secrets themselves were basically guids, they had quite a lot of characters. If sent MORE than 1 character, pretty low chance they would clash. But those long guids also covered a lot of letters and number - it wasn't terribly difficult to find one single character that cleared authorization reliably.

And maybe you're joking lol, but multitenant meaning multiple businesses/customers using the same application stored in the same database. If Bob's construction wanted to spy on Jim's contracting, they'd just need to know the right header to send and could get whatever they wanted from the other customer partitions. User access should of course be limited to their own assigned partitions.

[–] vrek@programming.dev 4 points 2 days ago

Oh, ok I interpreted multitenant wrong. I was thinking it was like a apartment complex so you have like a manager and a sales person with access and that's it. Still a valid security risk but not as severe as what you are saying now.

Sorry for confusion

[–] Hasherm0n@lemmy.world 3 points 1 day ago

I once saw an application that would encrypt (not hash, encrypt) passwords but then when a user was logging in, they'd encrypt the password candidate and then compare the cipher texts to see if they were the same. This was using 3des, so no IV.