To avoid using the credentials completely, decouple the trigger of the cache warming script from the server-side event.
The concept is:
- server-side event sets a flag in a shared location
- persistent process run by cache warming script user monitors that shared location
- if persistent process sees flag is set, flag is cleared and cache warming script is run
Since the persistent process can be run via cron or as a daemon owned by the cache warming script user, you just set that up once, never need to pass user account credentials.
Decide on a shared location that can be accessed and written to both by the server-side event and the user that needs to run the cache warming script. In a system with a database, this could be a variable in a configuration table. But this could also be just a file in a directory that is +rw by both users and is touch'd by the server-side event.
Setting the flag:
If you are using a database, an example of setting a flag would be if you have a variables table that has key and value columns, setting a particular key's value to 1. If its a file, it would be the existence of a file.
If you need to restrict how often the cache warming script is run, you can always implement logic in the persistent process to keep track of the last time the script was run to prevent overuse if something goes bad.
You can easily add multiple triggers of the cache warming script from other server-side events because the method of triggering the script is hidden behind the shared location interface.