Improve developer onboarding

[fapdash]

I've already worked on this a bit in https://github.com/Alovoa/alovoa/pull/150 but currently it's not straight forward to set up a dev environment. What is your reasoning for not including a development application profile? A dev application.properties file should not contain any sensible information anyways. If we define some default values for the dev environment then we can also provide setup (bash) scripts that set up additional services as the default properties file expects it.

In my experience it is the best to include development and production properties files and either load all secrets through environment variables or through an extra 'secrets' profile, so all the secrets are in application-secrets.properties, which is not included in the repository. You would provide a application-secrets.properties.example file through, so people know what to fill in / provide default values there. This makes it easier for contributors and people who want to self-host to see how everything works together.

I also noticed that the project doesn't use spring-boot-devtools. Developing without hot code reloading is not very pleasant. Would you accept a PR adding the devtools?

[Nonononoki]

In my opinion the default application.properties is already sufficient. If you look at your own PR (https://github.com/Alovoa/alovoa/pull/150/commits/f1ca4edcdb010a54083afe4de3d406bed67d892a), most, if not all values of the properties file are credentials and keys.

Currently I reboot with a custom script, not very elegant but does its job. Feel free to create a PR for spring-boot-devtools. Keep in mind that a decryption key is needed decrypt data in the database and keeping the key locally in plain text is not acceptable.

Does this answer your questions?

[fapdash]

I usually deactivate thymeleaf caching in the dev environment and activate it in the production profile, which shortens the feedback cycle during development. Otherwise you have to restart the server to see changes.

Keep in mind that a decryption key is needed decrypt data in the database and keeping the key locally in plain text is not acceptable.

https://github.com/Alovoa/alovoa/blob/5d1035c8b44859207ae0dac07aa749b0c29a5fba/scripts/deploy-prod.sh#L8

Is this the key you are talking about? Not sure I fully understand.

[Nonononoki]

I remember that there was an instance where I couldn't figure out why the cache was not working, until I realized that I disabled it in the dev environment. It's enabled by default ever since on my machine.

Is this the key you are talking about? Not sure I fully understand.

The script will ask for the key after mvn install, which is written (as plaintext...!) as an environment variable. Then the spring boot app reads saves the key into memory and the env variable is then cleared after a few seconds. Not very elegant, but it was the only way I knew how pass a parameter to the jar file without it being visible.

[fapdash]

I remember that there was an instance where I couldn't figure out why the cache was not working, until I realized that I disabled it in the dev environment. It's enabled by default ever since on my machine.

Are we talking about the same cache? I'm talking about the thymeleaf cache, which stops changes to the thymeleaf templates to show up immediately. Not bucket4j.

Not very elegant, but it was the only way I knew how pass a parameter to the jar file without it being visible.

If someone has access to root then you probably have lost anyways (keylogger), so I think it's fine to populate this through a systemd unit file, which can only accessed by root. You could unset the env via ExecStartPost. But I don't work in infosec, so take that with a grain of salt.

[fapdash]

Just checked and in systemd you could do something like this:

ExecStartPre=/bin/sh -c "systemctl set-environment SECRET=mypassword"
ExecStartPost=/bin/sh -c "systemctl unset-environment SECRET"