When a push expires, the password (payload) is deleted immediately from the database. What remains is the push record with its metadata (expire settings) and the audit logs for this push.

The following background jobs help in preemptively expiring pushes, deleting old records that are no longer needed and more.

Note: If you are self-hosting the pglombardo/pwpush Docker container, as of release v1.53.0, these background tasks are run automatically for you and can be managed in the Administration Dashboard.

Explanation & Background

Terminology

Push - one record in the Push table and its related audit log. This includes the payload and the metadata about the push such as expiration settings.

Payload - The sensitive data posted by the user. e.g. The password, text, file(s) and reference note.

Job - A unit of work that runs asynchronously outside of the main request/response cycle, often scheduled to run at a specific time or after a delay.

Periodic Expiration & Cleanup

Password Pusher bundles background tasks that can be run periodically on your instance to:

  1. run through all unexpired pushes, validate and conditionally expire them
  2. delete expired and anonymous records

Jobs

Bundled Jobs

The jobs bundled into Password Pusher are:

  1. CleanUpPushesJob - Deletes expired & anonymous pushes. Anonymous pushes (created by anonymous users) don’t have an accessible Audit Log so have little value and are removed entirely after expiration.
  2. ExpirePushesJob - runs through all unexpired pushes and checks whether they should be expired and the payload deleted
  3. PurgeUnattachedBlobsJob - cleans up failed and/or partial uploads

Background Worker System

As of release v1.53.0, the background worker system is included in the main pglombardo/pwpush container and runs automatically. No additional configuration is required.

To disable the background worker system, set the PWP__NO_WORKER environment variable to true:

docker run -e PWP__NO_WORKER=true pglombardo/pwpush

Using the Worker Container

Alternatively, you can run the background jobs in a separate container using the pglombardo/pwpush-worker image:

docker run pglombardo/pwpush-worker

This container runs the same background jobs but in a dedicated container. This can be useful for:

  • Separating concerns between web and background processing
  • Scaling background processing independently
  • Running in environments where the main container cannot run background processes

The worker container requires the same environment variables, volumes & configuration as the main container to connect to the database and other services.

Manually Running the Background Jobs

Running Jobs via the Administration Dashboard

The built-in Administration Dashboard has a “Background Jobs” area.

From this page, you can run background jobs manually.

Note: As of release v1.53.0, these jobs are run automatically on a recurring schedule. Running manually is optional.

Running Manually From the CLI

Warning: The ability to manually run these jobs as described below may be removed in the near future as the new jobs have been moved to a background job framework in the Administration dashboard described above.

These tasks live in lib/tasks/pwpush.rake and can be run as follows:

/opt/PasswordPusher/bin/pwpush daily_expiration
/opt/PasswordPusher/bin/pwpush delete_expired_and_anonymous

Heroku Example:

heroku run --app=mypwp pwpush daily_expiration
heroku run --app=mypwp pwpush delete_expired_and_anonymous

Notes

  • These tasks will delete unnecessary data from your Password Pusher instance. You should make a backup of your data as a precaution before running these tasks. I run these tasks daily on pwpush.com so they are tested and reliable.

  • When a user requests to see a secret URL of an unexpired push, the application first validates if that password should be expired by re-validating the expiration settings. If the push is past it’s expiration, the push payload is deleted from the database and the user gets the “This secret link has expired” message. The daily_expiration task serves to expire passwords preemptively which saves on some CPU and database calls ahead of time.

  • The secret URLs for deleted records will still show the “This Secret Link Has Expired” message as that is the default even when the secret URL is not found. This is done for two reasons:

    1. To hide the fact if a push ever existed at a certain secret URL
    2. We don’t want data for expired anonymous pushes so we delete it and show the “This Secret Link Has Expired” message as default so that old secret URLs will still be correct with the expiration message.

  • Pushes that are owned by logged in users are never deleted (although their payload may have been) by these tasks so that audit logs can be maintained.

  • More strategy and reasoning is available in the task definitions to further explain the how and why it works this way

Other Jobs

Maintenance Mode

Maintenance mode is a mode in which the application refuses to serve pages and instead displays a maintenance page for all request paths.

This is useful if you have to perform maintenance on your instance or if you would like to block access for a certain amount of time.

Enabling & Disabling

To enable, proceed to step 4 here and run the following command:

./bin/rake maintenance:start

and to end the maintenance:

./bin/rake maintenance:end

More Info

This functionality is implemented using the turnout2024 gem. More features, options and commands are available on that page.

Updated: