This branch does away with the initial generation of captchas. Instead, as each captcha is requested it creates a job on a queue to create a new one, the new one is supplied on the next request. This means every GUID and image is unique and never repeated. This prevents scripts 'remembering' either the guid or taking a hash of the image content.
In development mode (a new config setting) the captcha is always generated with an answer of '1'.
Captchas older than 1hr are purged from both the file-system and the database.
This has been tested in a docker container, both with and without 'develop_mode' so all code paths have been tested, however since there are no TTF images in a docker container this will need to be tested on the PT server to be sure.
In addition, schedule_buildings and schedule_ship_arrival scripts have had the automatic 1hr timeout removed. This is redundant, if a cron job is running to restart the scheduler then the old job will be stopped anyway, if not then the scheduler runs forever.
This branch does away with the initial generation of captchas. Instead, as each captcha is requested it creates a job on a queue to create a new one, the new one is supplied on the next request. This means every GUID and image is unique and never repeated. This prevents scripts 'remembering' either the guid or taking a hash of the image content.
In development mode (a new config setting) the captcha is always generated with an answer of '1'.
Captchas older than 1hr are purged from both the file-system and the database.
This has been tested in a docker container, both with and without 'develop_mode' so all code paths have been tested, however since there are no TTF images in a docker container this will need to be tested on the PT server to be sure.
In addition, schedule_buildings and schedule_ship_arrival scripts have had the automatic 1hr timeout removed. This is redundant, if a cron job is running to restart the scheduler then the old job will be stopped anyway, if not then the scheduler runs forever.