He was a subcontractor, so technically, he’s not our employee.
I bubbled it up the chain on our side, and it hasn’t happened since.
Comment on Privacy disaster as LGBTQ+ and BDSM dating apps leak private photos.
Serinus@lemmy.world 1 week agoHow is he not fired? Incompetence and ignorance is one thing, but when you combine it with effectively insubordination… well, you better be right. And he is not.
yoshman@lemmy.world 1 week ago
Pika@sh.itjust.works 1 week ago
Firmly agree, I don’t believe he should have had access to change these password in the first place unless I’m misunderstanding their definition of test engineer, but if OP had the authority and permission to change the password in the first place, and that person deliberately changed it back to the insecure route again, there would some sort of reprimandment involved
yoshman@lemmy.world 1 week ago
It was an admin account to do regression testing for the admin interface and functions before prod releases.
I had my guys enable/disable the account during the testing pipeline so people can’t login anymore.
sugar_in_your_tea@sh.itjust.works 1 week ago
Why would you have regression on prod? Or why would you care what the password is on staging environments?
We have our lower environments (where all testing happens) on a VPN completely separated from prod, and testing engineers only ever touch those lower environments. Our Ops team manages all admin prod accounts, and those are completely separate from lower environment accounts.
So I guess I’m struggling to understand the issue here. Surely you could keep a crappy password for pre-prod testing? We even create a copy of prod as needed and change the admin accounts if there’s something prod-specific.
yoshman@lemmy.world 1 week ago
The production database gets down-synced to the lower environments on demand, so they can test on actual production datasets. That would require us to manually remake this user account every time a dev down-syncs the database to a lower environment.
The customer is paranoid, as the project is their public facing website, so they want testing against the actual prod environment.
We don’t mange the SSO, as that is controlled by the customer. The only local (application specific) account is this account for testing.