3 ms·
> Instead one of your gremlins ran this function directly on the production machine. Exactly my first hypothesis too. But then keepthescore claims, > of cours
by skytreader 6y ago
> Instead one of your gremlins ran this function directly on the production machine.
Exactly my first hypothesis too. But then keepthescore claims,
> of course we use different passwords and users for development and production.
How would this hypothesis explain that?
---
Metadialogue:
John Watson: "I deduce that someone changed the dev config source so that it uses the production config values."
Sherlock Holmes: "My dear Watson, while that is sensible, it seems to me that the balance of probability leans towards their production instance also having the development access credentials."
---
Just my way of saying, I think this case isn't as shut and closed as most comments (including parent) imply. I personally find the /etc/host mapping a likelier hypothesis but even that can't explain how different credentials failed to prevent this. Without more details coming from a proper investigation, we are just piling assumptions on top of assumptions. We are making bricks, without enough clay, as Holmes would say.
- thamer 6y agoAgreed, it seems like most people making suggestions above are missing the point about credentials. The code they present explicitly references `config.DevelopmentConfig`: database = config.DevelopmentConfig.DB_DATABASE user = config.DevelopmentConfig.DB_USERNAME password = config.DevelopmentConfig.DB_PASSWORD One way this could happen is if the objects under `config` were loaded from separate files, and the dev file was changed to a symlink to the prod file. So `config.DevelopmentConfig` always loads /opt/myapp/config/dev.cfg but a developer had dev.cfg -> prod.cfg and the prod credentials and connection details were loaded into `config.DevelopmentConfig`. Just an idea.