solidtime-io
Accessing /admin yields 403 forbidden error if no validated user has been set
I have installed Solidtime and added a "super admin" user in the laravel.env configuration file as I have not set up my NAS for receiving mails and never will, as I don't need that. However, accessing the /admin panel yields a "403 forbidden" error, so I had to manually change the database entry for my user and set the "email_verified_at" field. This is inconvenient and quite user unfriendly, and I was expecting the ‘super admin’ user to be able to access everything without a confirmed email, but this is not the case.
I would like to request the following change: Allow a default user to be enabled that can access Solidtime as an administrator. This user could either be set in the environment settings or the first user that is created automatically becomes the administrator and has access to everything.
Thanks for your feedback. This behavior is done on purpose. Since super admins have brought access to the application, we think it is a good idea to require an extra security layer.
Imagine the following scenario: You have a company and you have five super admins. One super admin leaves the company, and you delete their account to block their access. Normally, you would assume that this is enough, but since you forgot to remove their email address from the SUPER_ADMINS env, everyone that guesses or knows the email address of the former employee can get super admin access, by just signing up with that email address. To prevent this from happening accidentally, we added this extra step.
I get that this is annoying for self-hosting setups without the need to send emails for solidtime. To be able to verify an email without setting up email sending, you can use the log driver. See in the docs here: https://docs.solidtime.io/self-hosting/configuration#test-via-log
We can also add an artisan CLI command to verify the emails of account manually. Would this help you?
Thank you for the quick reply, much appreciated. In my opinion, the responsibility for any security related matters lies within the admin and not the Solidtime application. You can't cover all security related concerns anyway, and as it currently is, there is an added layer of complexity that isn't necessary and makes it quite inconvenient to set up a Solidtime instance. A SUPER_ADMIN should be just that, an admin with access to everything without any extra stuff to care about.
A CLI command to verify mail accounts manually would definitely help. The best solution would be to clearly separate the concerns though, the Solidtime app is responsible for the time tracking, any security related matters should be handled by the person setting up the Solidtime instance.
Regarding security related matters, the "APP_FORCE_HTTPS" setting in laravendel.env doesn't seeem to have any effect. I tried setting it to "false" and "", but I still get SSL errors when trying to access Solidtime via HTTP. I solved that by setting up a reverse proxy, but that is something I don't consider necessary for a local Solidtime instance either. Is that a bug or did I misunderstand the meaning of APP_FORCE_HTTPS?
To end on a positive note: I really like the clean UI design of Solidtime, the application is simple and easy to use and doesn't have any unnecessary features. Well done! :)
@RKLBusinessDevelopment I'm glad you like solidtime! :)
I just pushed an artisan CLI command named admin:user:verify. That can be used to manually verify accounts.
The documentation is currently meant for production/public setups. That is also why we write in the documentation (here) that a reverse proxy is required and the env APP_FORCE_HTTPS is not explained, since a public setup should have this set to true. If you work locally, and you don't need SSL, it is possible to run solidtime without a reverse proxy.
Regarding the APP_FORCE_HTTPS variable: If set to true, the application assumes every incoming request is HTTPS. This is helpful if you are running solidtime behind a reverse proxy and the communication between user and reverse proxy is always HTTPS, but communication between reverse proxy and application container is HTTP.
We'll update the documentation to include local setups as well, in the near future.