Level 73
I would place it in a Database class, that way I will only have it in one place.
1 like
Jul 11, 2023
18
Level 8
Where to place code that checks for successful PDO connection?
Hello,
I need to check if there is a successful PDO connection on every request:
try {
DB::connection('conn1')->getPdo();
} catch (Exception $exception) {
// do something
}
Where is a good place to place it?
Level 8
@Tray2 would you create it as a provider? Or just class in App/Classes/Database.php for example? And then, where would you initialize it to be called on every request?
Level 122
@Ligonsker service providers are called on every request .
Is your database connection unreliable then?
1 like
Level 73
@Ligonsker Are we talking a php application without any framework, or are we talking about a laravel app?
1 like
Level 51
On every request? I would do that in the middleware.
But why would you do that?
1 like
Level 8
@tray2 Laravel app @snapey @mohamedtammam, the DB password changes on a daily basis at an unknown time so if the connection fails, I update the ENV accordingly from another API that sends the password (an internal API)
So the first user that gets the wrong password basically updates the ENV file on the server. I do however know that it's really bad, connecting to the DB on every request. But is there any better way to do it in this situation?
Level 51
@Ligonsker In that case you can create an error handler for when the database connection fails: https://laravel.com/docs/10.x/errors#reporting-exceptions
However, I would try two approaches instead:
- Create a webhook that being called when the database password changes and handle updating the password that way.
- Run a corn job every second/minute depends on the use case to check against the database connection.
1 like
Level 73
@Ligonsker That is a really shitty and unsafe setup. Why the hell would you need to change the password every day?
Are we talking mission controll for nukes here?
1 like
Level 122
@Tray2 for safety, it changes every day, but don't worry, there is a handy API where the new one is exposed !
1 like
Level 73
@Snapey My point exactly.
1 like
Level 80
@Ligonsker Mate. WTF? 😬
Your company wouldn’t need to expose a database password via an API if they just used bloody environment variables. All they’d have to do is update the environment variable. Your application wouldn’t care; it will just use whatever value is in the environment, and then passwords are being sent in plaintext over network calls.
Think whatever company you work for really needs to hire someone who actually knows security, because you keep saying they do all these restrictions and workarounds in the name of “security”, but then every “solution” just sounds utterly insecure.
2 likes
Level 8
@martinbean @tray2 @snapey it's not really an API, maybe I exaggerated calling it API, since I use PHP to run a script to call the password, but in reality it's some other system where I pull it from some software via script
it's originally meant for something else but we happen to also need it from there
Level 80
@Ligonsker The proper solution to this is to just set environment variables on whatever systems need this database password, and that way they don’t need to do any calling of APIs or scripts, or any error handling—the application just uses the password set in the environment.
If scripts or APIs are sending passwords around then there is far too many touch points where that password is passing through as plaintext.
2 likes
Level 8
@martinbean true, this is not a good way and I Should talk to IT. When you say environment - you mean like System environment variables in Windows?
I am using Windows server so I want to know what I can tell them to improve that.
For example on the Windows server - create a system environment variable DB_PWD which will hold the latest password?
Level 80
When you say environment - you mean like System environment variables in Windows?
@ligonsker Yes.
For example on the Windows server - create a system environment variable DB_PWD which will hold the latest password?
No. There already is a variable for the database password: DB_PASSWORD: https://github.com/laravel/laravel/blob/04a8e8553e6bf0ed54f5136949d7152df025dd91/.env.example#L16
You don’t need to start making your own up. Just have whatever team keep the DB_PASSWORD environment variable up to date with the latest password. That way, your application doesn’t need to check anywhere, or write error handling logic to check an API for a new password—it’s just there, in the environment, ready to be used.
All an .env file is, is a convenience on top of actual environment variables. You should be using actual environment variables where ever you can, such as a server. If you set environment variables, then you don’t need an .env file on the server at all.
Level 8
@tray2 @snapey 😂🤣 haha I know but it's not my decision 😁
But also, the API is very strict to who can use it and it's logging every information so I guess the IT guys want highest security possible even if it's only adding a little bit security. It's not nukes, but it's financial 😅
@mohamedtammam cron job every second is OK? I never had a cron running so frequently. Regarding web hooks, I am not sure they have that option to capture when it changes, but I do need to check it out.
Regarding the error handler - in what place in the Laravel project do you recommend putting it for every request (Until I figure a better solution at least)
Level 122
@Ligonsker in the exception handler. It only gets called when there is an error, so no extra load on the other requests.
1 like
Level 75
I suggest just following laravel conventions and apply correct authentication and authorization.
Even with a different connection if your authentication and authorization isn't right what good is a different connection.
1 like
Please or to participate in this conversation.