I had my application configured and deployed with a database that already had some records, today without knowing why the credentials have changed and with it the access to the database.
I would like to know under what parameters and how often Heroku does this kind of thing.
Related
My problem is that sometimes when I do a new code deployment to AWS Elastic Beanstalk and I already have active session (am logged as myself), then when I refresh the page, I'm logged in as someone else. I use database sessions. This doesn't happen too often - or at least I'm not aware of it but can't figure this out. I'm using standard Laravel login functionality. I'm trying to find at least a start point how/where to start investigating. It has to do something with the deployments to Elastic Beanstalk because that's when this sometimes happen. I would have imagined that using database session shouldn't be affected by code changes on EB. Any help would be appreciated.
Heroku sent an email regarding scheduled maintenance for a hobby-dev hosted Postgres database I have. I received confirmation that the scheduled maintenance had been successfully completed and that my updated database credentials would reflect this.
After updating the environment variables in my app to reflect this change, I can no longer connect to the database. Scheduled maintenance changes have completed before with no issues, this is the first time I'm receiving this error.
Authentication failed against database server at `ec2-176-34-114-78.eu-west-1.compute.amazonaws.com`, the provided database credentials for `mydb` are not valid.
However, when I log into Heroku to view the database instance, the health checks are showing that it's available.
I've now tried using the new and old database credentials, but both are unable to connect to the DB. It also appears that I am unable to directly contact support on the hobby dev plan.
Do I have any other options to try troubleshoot this? Is it possible to force a new database credential update on Heroku?
Yes, you can use heroku pg:credentials:rotate to generate new credentials. But you shouldn't have to do this.
After updating the environment variables in my app to reflect this change
As the email told you, your credentials would automatically have been updated. There was nothing for you to do. As long as you are connecting via the DATABASE_URL environment variable, which is always recommended with Heroku Postgres¹, you should be good to go.
heroku pg:credentials:rotate behaves the same way, so running that command without understanding this isn't likely to help much.
¹Heroku may update these credentials at any time. Connecting via that environment variable is the best way to ensure you can always connect.
I have provisioned postgres on my heroku app and also installed postgres locally to maintain parity (as the documentation recommends) with the online database but I'm also not understanding how this will work. Am I supposed to be accessing a local copy of a database when running on my own computer (while building and before deploying) and then using heroku's separate postgres database once it is deployed? If it is parity, shouldn't they both be using the heroku postgres database?
In other words, will my local app (during production) and heroku app (deployed and live) be using the same online postgres database?
Thanks.
Am I supposed to be accessing a local copy of a database when running on my own computer (while building and before deploying) and then using heroku's separate postgres database once it is deployed?
Yes, that's exactly it. Without seeing what bit of documentation you're referencing it's hard to say what they mean but perhaps there's another way to explain it.
In your local development environment, you may find that you need to test database schema changes (this is just one example, there are many). If you only had the one heroku postgres database you'd be forced to test these changes in production, which might result in poor usability for your users and that doesn't even account for the possibility of making a mistake and accidentally destroying your production data. There are a number of other shortcomings and challenges with this single database configuration.
For these reasons and more, it's best to keep your production data completely separated from your development/staging/test environment by creating a local/staging database. You might reasonably ask, "What about the data? I need data to test!". There are many ways to put together your test database and which you choose will likely depend on your needs. A shortlist of possibilities:
Use a seed file to generate mock data in your db
Use a model factory (usually runs in conjunction with your testing framework)
Take a dump of your production database, anonymize and redact sensitive information and use that for local testing.
I have built out a production API leveraging Laravel 5x (lets say api.test). I have gotten to the point now where I need to create a sandbox environment for users of the API to test out the API to without muddying up the live data (lets say sandbox.api.test)
I could obviously spin up an exact clone of my current production environment and keep everything separate auth, keys, etc.
Ideally I would want the authentication pieces of the sandbox to point at the production database so that users would not have to create new user accounts and separate oauth keys from passport.
What I am struggling with his how I could point anything authentication related so users/passport to my production environment and keep the rest of the DB actions local to sandbox.api.test
I know I can create a new connection in database.php but how then in my sandbox code do i update auth and oauth... is that even possible?
Citti
I am building an ETL Application that needs to fetch data from Heroku Postgres DB a few times a day but the application is not running on Heroku, I am already able to do this, but using the current credentials, but heroku states that the credentials are not permanent and will be rotated from time to time.
What is the best way to do this, building a REST API on top of my app is not viable an option. I have seen that Heroku provides a config vars API which I could potentially use to fetch the DB credentials, but is there a simpler/cleaner way for implementing this, is enforcing permanent credentials an option?
There is no way to enforce it. And it's not a question of credentials, but a question of a database hostname. It's ec2.
Your safest bet is to always fetch current DATABASE_URL from your Heroku app. If you only need to do it 'a few times a day' this is not a problem.