To add to this a bit, you're using Heroku for hosting and Github actions for CI/CD. In that case, your database connection string is already being provided to you via an environment variable on the Heroku side, specifically DATABASE_URL by default. One reason they do it this way is the case mentioned above, but the other reason is that your connection string may change over time. Specifically with Heroku (though I would guess other similar hosts perform similarly), your database may move to a different host as they perform regular maintenance. If you have your connection string hard-coded, your application will start throwing errors out of nowhere. If you use the environment variable they provide, they will also do the work of updating it for you and spinning up a new dyno with the correct information.
That said, that's all secondary to the security issues already mentioned which are significant and Github actions definitely allows you to specify environment variables in your pipeline and that's the way to go. On Thursday, October 14, 2021 at 4:49:02 AM UTC-4 Brian Candler wrote: > Your application should never panic. If the cookie is invalid, treat it > as if the cookie were not set at all, and redirect to the login page. > > As for security: I urge you to think again. I can see your postgres > instance blocks connections from unknown source IPs in pg_hba.conf, but > that's a fortunate backstop and is very weak. You're still letting the > whole world know your passwords, which are your primary security control. > > The fact that it's easy to make something work in an insecure way is not > the answer. You need to find the *right* way to make this work. Your > chosen CI/CD will have a way to provide secrets to the application; please, > learn about it and use it. > > On Thursday, 14 October 2021 at 09:31:38 UTC+1 muhorto...@gmail.com wrote: > >> Answering the first one, my server panics with the error: secure cookie: >> the value is invalid. >> The error occurs if I restart the server and the session is saved in the >> browser. >> For me, it's enough just to delete this value from the browser so that >> the server starts without panic, >> but I would like to do it normally. >> Answering the second, I have CI/CD, which is easier to work with, but >> gitignore will not allow the application to connect to the database >> immediately on the hosting. >> I would like the code to be public and CI/CD to work without problems >> >> четверг, 14 октября 2021 г. в 10:14:08 UTC+3, Brian Candler: >> >>> 1. If you are getting a panic, then you should show the complete error >>> message together with the backtrace, and it will help someone diagnose >>> what's going on. I don't think that simply having stale sessions in your >>> cookie store should cause your program to crash. Indeed, that's one of the >>> benefits of having a persistent cookie store: it should allow your >>> application to be restarted and users' existing sessions should continue >>> unaffected. >>> >>> 2. Do you realise that you've just given the entire world the >>> credentials to access your database? >>> >>> https://github.com/MukhortovDenis/goproject/blob/main/cmd/web/handlers.go#L22 >>> >>> You should keep secrets out of your source code. If your hosting setup >>> lets you pass environment variables to your application at runtime, that >>> would be an easy way to fix it: use os.Getenv() >>> <https://play.golang.org/p/-CplX2jEebO>. Or put the secret into a >>> separate file that you read when the application starts, but you don't >>> commit to version control (use ".gitignore" to prevent it being added by >>> accident). Or pass it as a command-line argument. >>> >>> This is good practice even if the source code were kept private. >>> Passing configuration to your application lets the same code be used in >>> dev, test and production environments. >>> >>> On Thursday, 14 October 2021 at 06:34:54 UTC+1 muhorto...@gmail.com >>> wrote: >>> >>>> Hi, there! How to properly clean up sessions after before >>>> disconnecting >>>> the server or before starting it? have a problem that the server >>>> is on a free hosting that periodically shuts down the server. >>>> Since cookies are stored with me and they are no longer relevant, >>>> my server is panicking. This is also necessary for local testing. >>>> What to do and what to use in such cases? >>>> https://github.com/MukhortovDenis/goproject >>>> >>> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6e14e0b3-8d81-436d-9893-f7fb80eac8b8n%40googlegroups.com.