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
hjk10138341y@rooter it should never be a formula and never in code.
If there is a master password it should be stored as a hash and loaded from the environment or something (also easy to have a different fixed password for testing)
devJs10071ywhy just not env that var just for QA instance so it doesn't end in prod?
EDIT: unless they do QA on prod! XD
Root802051yWhy would it be used by testers?
Are they testing in production?
Everything should be fully covered by unit and integration tests, automated frontend tests, and should not use real data.
I have heard decent cases for “sanitized” real data, however, as cases found in the wild are often more convoluted than random data.
But for multi tier logins, logging in as (or more accurately: impersonating) lower tier users is pretty common.
Testers should have their own test accounts wich have access to fake business objects used only in testing.
If a dev has to debug a corner case, he can still do that on a dev system using a copy of the production DB where he overwrote the original user's password hash with his own (either directly by using SQL or by using some admin menu where he can just set a new password).
Or implement an impersonation system (don't forget to log who impersonated whom from when to when).
This makes me want to never use any service again
Hazarth47601yso it's like:
sudo facebook.com login -u anyUserIWant
zemaitis7My local ISP was saving their database backups in an unprotected folder which was literally domain.com/backups...
PonySlaystation8There was a time in Windows 95, where during login, you could just press cancel and you were logged in without...
netikras18Colleagues sharing passwords.That was a big fat NO when I was a sysadmin - and for a good reason. But now, sin...