starred/koel-koel

Fork 0

mirror of https://github.com/koel/koel.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #1302] How to override DEFAULT_ADMIN_EMAIL and DEFAULT_ADMIN_PASSWORD #751

New issue

Closed

opened 2026-02-26 02:34:10 +03:00 by kerem · 8 comments

kerem commented

2026-02-26 02:34:10 +03:00

Owner

Originally created by @acjohnson on GitHub (Apr 5, 2021).
Original GitHub issue: https://github.com/koel/koel/issues/1302

Describe the bug
When I run php artisan koel:init --no-interaction --no-assets I am no longer able to override the admin email and password as I used to using ADMIN_EMAIL and ADMIN_PASSWORD as these env vars have been removed in this commit 4432ad6c21

Might not be a bug, but am I missing something obvious? Thanks!!

Originally created by @acjohnson on GitHub (Apr 5, 2021). Original GitHub issue: https://github.com/koel/koel/issues/1302 **Describe the bug** When I run `php artisan koel:init --no-interaction --no-assets` I am no longer able to override the admin email and password as I used to using `ADMIN_EMAIL` and `ADMIN_PASSWORD` as these env vars have been removed in this commit 4432ad6c215500d6d808650fbeb542e69b14da4f Might not be a bug, but am I missing something obvious? Thanks!!

kerem closed this issue

2026-02-26 02:34:10 +03:00

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@MichaIng commented on GitHub (Apr 11, 2021):

Looks like a regression to me, as now by default the web interface is accessible via publicly documented default credentials. If plain text passwords in the config file are to be avoided, probably command line options for koel:init could be added to override the default username, password and email address?

@MichaIng commented on GitHub (Apr 11, 2021): Looks like a regression to me, as now by default the web interface is accessible via publicly documented default credentials. If plain text passwords in the config file are to be avoided, probably command line options for `koel:init` could be added to override the default username, password and email address?

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@phanan commented on GitHub (Apr 11, 2021):

You can (and should) always log into Koel with the default admin credentials post-setup and change them, no?

@phanan commented on GitHub (Apr 11, 2021): You can (and should) always log into Koel with the default admin credentials post-setup and change them, no?

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@phanan commented on GitHub (Apr 11, 2021):

@MichaIng Yes, you can modify the default admin password: https://docs.koel.dev/#reset-admin-password.

@phanan commented on GitHub (Apr 11, 2021): @MichaIng Yes, you can modify the default admin password: https://docs.koel.dev/#reset-admin-password.

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@MichaIng commented on GitHub (Apr 11, 2021):

You can (and should) always log into Koel with the default admin credentials post-setup and change them, no?

But until this is done, Koel is basically unprotected. While is sounds contradictory, on the other hand the default credentials are not documented, like here where the web UI URL is mentioned to "start using Koel": https://docs.koel.dev/#building-from-source
At that point, users might be stuck until finding https://docs.koel.dev/#reset-admin-password.

Also, removing the config settings broke the ability to automate a secure setup, since koel:admin:change-password requires interactive input. Probably it can be allowed to add the password via second command line option or STDIN? I know a command line argument implies the issue of passwords being seen on the console, but it would still be optional and could be scripted in a safe way where the password is randomly created or read from a safely stored file.

@MichaIng commented on GitHub (Apr 11, 2021): > You can (and should) always log into Koel with the default admin credentials post-setup and change them, no? But until this is done, Koel is basically unprotected. While is sounds contradictory, on the other hand the default credentials are not documented, like here where the web UI URL is mentioned to "start using Koel": https://docs.koel.dev/#building-from-source At that point, users might be stuck until finding https://docs.koel.dev/#reset-admin-password. Also, removing the config settings broke the ability to automate a secure setup, since `koel:admin:change-password` requires interactive input. Probably it can be allowed to add the password via second command line option or STDIN? I know a command line argument implies the issue of passwords being seen on the console, but it would still be optional and could be scripted in a safe way where the password is randomly created or read from a safely stored file.

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@phanan commented on GitHub (Apr 11, 2021):

But until this is done, Koel is basically unprotected.

This is right, but I don't think there's a real risk here, provided that you're the one who set the system up and should be the only one knowing about its existence by then.

on the other hand the default credentials are not documented

This is intended. The credentials are only shown during installation.

Probably it can be allowed to add the password via second command line option or STDIN?

Yeah, I'm open to a PR 🤗

@phanan commented on GitHub (Apr 11, 2021): > But until this is done, Koel is basically unprotected. This is right, but I don't think there's a real risk here, provided that you're the one who set the system up and should be the only one knowing about its existence by then. > on the other hand the default credentials are not documented This is intended. The credentials are only shown during installation. > Probably it can be allowed to add the password via second command line option or STDIN? Yeah, I'm open to a PR 🤗

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@MichaIng commented on GitHub (Apr 11, 2021):

This is right, but I don't think there's a real risk here, provided that you're the one who set the system up and should be the only one knowing about its existence by then.

This includes quite some assumptions, about the location of the terminal, where it is set up, that the user is watching the install process and logs into the web UI to change credentials (or uses the CLI command) as fast as the install is done, that there is no random port scan bot by chance hitting that much used 5000 default port and all such. I mean yeah, usually it is not a risk, I agree, but it is never a bad idea to cover unusual cases and situations, dumb users and collisions of some more coincidences as well 😉.

Little background: I'm implementing/fixing an automated install script for Koel for a large number of end users, and the goal is to allow running it along other first boot setup steps and other software installs completely unattended, without having any network application listening on standard ports with default credentials, so that it is safe to finish setup at any time later.

This is intended. The credentials are only shown during installation.

It is not, or did I oversee it? Check out the pastes of my koel:init call here: https://github.com/koel/koel/issues/1298#issuecomment-816872063
The only part where I did see at least the admin email, was when running koel:admin:change-password, while for the password I needed to check the PHP script.

May I ask for the reason why the .env settings have been removed? Just in case it plays a role when implementing the ability to set credentials via CLI arguments or STDIN.

@MichaIng commented on GitHub (Apr 11, 2021): > This is right, but I don't think there's a real risk here, provided that you're the one who set the system up and should be the only one knowing about its existence by then. This includes quite some assumptions, about the location of the terminal, where it is set up, that the user is watching the install process and logs into the web UI to change credentials (or uses the CLI command) as fast as the install is done, that there is no random port scan bot by chance hitting that much used **5000** default port and all such. I mean yeah, usually it is not a risk, I agree, but it is never a bad idea to cover unusual cases and situations, dumb users and collisions of some more coincidences as well 😉. Little background: I'm implementing/fixing an automated install script for Koel for a large number of end users, and the goal is to allow running it along other first boot setup steps and other software installs completely unattended, without having any network application listening on standard ports with default credentials, so that it is safe to finish setup at any time later. > This is intended. The credentials are only shown during installation. It is not, or did I oversee it? Check out the pastes of my `koel:init` call here: https://github.com/koel/koel/issues/1298#issuecomment-816872063 The only part where I did see at least the admin email, was when running `koel:admin:change-password`, while for the password I needed to check the PHP script. May I ask for the reason why the `.env` settings have been removed? Just in case it plays a role when implementing the ability to set credentials via CLI arguments or STDIN.

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@phanan commented on GitHub (Apr 12, 2021):

It is not, or did I oversee it? Check out the pastes of my koel:init call here: #1298 (comment)

This is because you encountered a problem during installation. See github.com/koel/koel@4432ad6c21 (diff-2d7e48b8b). Nevertheless, I think this can be improved.

@phanan commented on GitHub (Apr 12, 2021): > It is not, or did I oversee it? Check out the pastes of my koel:init call here: #1298 (comment) This is because you encountered a problem during installation. See https://github.com/koel/koel/commit/4432ad6c215500d6d808650fbeb542e69b14da4f#diff-2d7e48b8b3c6e5dcd67fc7dc613cffab326e16b99b7b9e4fff11df5d1e6ee13cR82. Nevertheless, I think this can be improved.

kerem commented

2026-02-26 02:34:10 +03:00

Author

Owner

@MichaIng commented on GitHub (Apr 12, 2021):

Ah I see. In my case, the admin account was created successfully, but the installer errors out regardless afterwards, before the default credentials are printed. On next init call, setUpAdminAccount is not called anymore, as the account has been successfully created already, hence adminSeeded is not set to true, hence the info is never printed.

Probably the default credentials could be printed as part of the setUpAdminAccount, or better as part of maybeSeedDatabase after the db:seed call. On the other hand, having it at the end of all output is more convenient compared to having it somewhere in the middle. Fixing the false } catch (Throwable $e) { call is key in any case: #1304

@MichaIng commented on GitHub (Apr 12, 2021): Ah I see. In my case, the admin account was created successfully, but the installer errors out regardless afterwards, before the default credentials are printed. On next init call, `setUpAdminAccount` is not called anymore, as the account has been successfully created already, hence `adminSeeded` is not set to true, hence the info is never printed. Probably the default credentials could be printed as part of the `setUpAdminAccount`, or better as part of `maybeSeedDatabase` after the `db:seed` call. On the other hand, having it at the end of all output is more convenient compared to having it somewhere in the middle. Fixing the false `} catch (Throwable $e) {` call is key in any case: #1304

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/koel-koel#751

No description provided.

Rows
Columns