Push the password via Email

[shnsys]

Checklist

• I've searched the project's issues.
• I've searched the project's discussions.

❓ Question

How can I [X]?

Is it possible to [...]?
We have set up a private instance and would like to know if it is possible to push the password via email directly through the PWPush admin portal.

📎 Additional context

[github-actions]

Hello @shnsys, thanks for contributing to the Password Pusher community! We will respond as soon as possible.

[pglombardo]

Hi @shnsys - not possible yet but coming hopefully this summer.

[shnsys]

Hi @pglombardo, thank you for the update

Our objective is to create bulk passwords and directly forward them via the PWPush portal. Is there a workaround to achieve this? Where can I find the steps on creating the bulk passwords?

[pglombardo]

I'd like to add the ability to do this end to end but the project isn't there yet.

One potential solution is:

1. Generate a password in the CLI
2. Post the generated password to the Password Pusher API
3. Get back the secret URL
4. Email the secret URL with an email template from the CLI

For example, this is how you could use the API to generate a push with Password Pusher:

curl -X POST -H "X-User-Email: <email>" -H "X-User-Token: MyAPIToken" --data "password[payload]=mypassword&password[expire_after_days]=2&password[expire_after_views]=10" https://pwpush.com/p.json

Documentation on the API is here and get your API token here.

Alternatively, you could use one of the many OSS CLIs available: https://pwpush.com/en/pages/tools

I hope to have the end to end solution to this maybe this fall. There are some bigger features that have to go out first.

Does this help out at all?

[shnsys]

Hi, thank you. It looks like something I can try.

I got couple of more questions for you

1. We've set up our own instance with Docker. When I check the admin portal via /admin, I notice that the time zone is set to UTC. We've already configured the time zone in the settings.yml file, but it seems that this change hasn't affected the admin portal. Is there a way to adjust this?

2. What is the retention period for the audit logs? Can we adjust this to retain data for a specific number of days? This is to ensure we're not using unnecessary storage for audit logs. Also, how can we confirm that all the data saved in the database is encrypted?

[pglombardo]

We've set up our own instance with Docker. When I check the admin portal via /admin, I notice that the time zone is set to UTC. We've already configured the time zone in the settings.yml file, but it seems that this change hasn't affected the admin portal. Is there a way to adjust this?

Good on pointing that out. It's a bug. I'll fix soon. #2334

What is the retention period for the audit logs? Can we adjust this to retain data for a specific number of days? This is to ensure we're not using unnecessary storage for audit logs. Also, how can we confirm that all the data saved in the database is encrypted?

Currently, expired pushes (with audit logs) are never deleted. Since the storage is trivial, it hasn't made it to the top of the fix list yet.

Re: Encryption - The sensitive data is encrypted inside the database. These are the payload, reference note and passphrase. When a push expires the encrypted data is deleted entirely.

Also, how can we confirm that all the data saved in the database is encrypted?

The code is open source for this reason. It's been reviewed many times and been through a bunch of security audits over the years. See also this discussion which explains a bit.

Also make sure you set your own custom encryption key for your instance.

[shnsys]

Thank you for the clarification.

We are planning to delete the audit logs after x number of days using a scheduled task. Is it possible for us to connect to the database to run this schedule tasks? If so, what would be the best way to connect to the database?

[pglombardo]

We have Background Tasks that can be scheduled via cron but nothing to delete just audit logs.

Do you want to delete pushes and their audit logs entirely or just audit logs?

[pglombardo]

Hi @shnsys - Admin timezones have been fixed in v1.14.15 which is building now.

[shnsys]

@pglombardo , we are trying to delete both pushes and the audit logs to save up some space.

That is great! Thank you for fixing this so quickly. I tried upgrading the application but could not figure out the best way to do it without losing the data. I went through the documentation https://docs.pwpush.com/docs/upgrading/, but I'm not sure what the best way to refetch the image tag is.

We are currently running the image with the tag /latest. When I pull the recent Docker image, I cannot run it with the existing container running with the Postgres database. Therefore, I had to run the following command, which creates a fresh database with a new Docker instance: docker run -d -p "5100:5100" pglombardo/pwpush:latest -e DATABASE_URL=mysql2://pwpush_user:pwpush_passwd@mysql:3306/pwpush_db

I am new to Docker, so I'm not sure if I have missed anything.

[pglombardo]

@pglombardo , we are trying to delete both pushes and the audit logs to save up some space.

It's on the list to delete old pushes. I'll take another look at this soon. But note that this will save space in the order of kilobytes - nothing bigger. Expired pushes are only metadata (expiration settings, views etc.). It's almost nothing in terms of space.

That is great! Thank you for fixing this so quickly. I tried upgrading the application but could not figure out the best way to do it without losing the data. I went through the documentation https://docs.pwpush.com/docs/upgrading/, but I'm not sure what the best way to refetch the image tag is.

I updated that upgrading documentation. It now tells users to docker pull to refetch a tag.

We are currently running the image with the tag /latest. When I pull the recent Docker image, I cannot run it with the existing container running with the Postgres database.

Not sure I understand completely here but you have an external DB server that is either MySQL, MariaDB or Postgres - then DATABASE_URL just points there. When upgrading, you update the Docker container but keep the same DATABASE_URL (which has all the data).

I am new to Docker, so I'm not sure if I have missed anything.

No problem - I'm trying to improve the documentation to make it as clear as possible. Docker is a lot to take in the first time you come across it. It takes a while but it's worth it considering how widely used Docker is.

[shnsys]

@pglombardo
I doubt that my instance is running with PostgreSQL.

I am using the following command to start the container:

docker run -d -p "5100:5100" pglombardo/pwpush:latest -e DATABASE_URL=postgres://pwpush_user:pwpush_passwd@postgres:5432/pwpush_db -v /var/lib/pwpush/logos:/opt/PasswordPusher/public/logos

Whenever I run this command, I lose all data, which makes me think PostgreSQL is not correctly linked with the running Docker container.

I also ran docker-compose -f docker-compose.yml to start from scratch and found a permission issue with creating the PostgreSQL source folder /var/lib/postgresql/data. I updated the docker-compose.yml file to create this folder in the home directory, which resolved that issue. However, I still lose all data when running the command above. I noticed that the postgres:15 image is now running in the background, which was not there before.

[pglombardo]

Hi @shnsys -

The Docker container will output which database it is using on boot. I just booted without the DATABASE_URL environment variable and the boot logs look like this:

What do your pwpush container boot logs say?

[pglombardo]

I need to fix that wiki link. The new location is at: https://docs.pwpush.com/docs/how-to-universal/#how-does-it-work

[shnsys]

@pglombardo please see the below screenshot of the boot log

[shnsys]

@pglombardo, thanks to your new documentation on https://docs.pwpush.com/, I was able to configure the server from scratch, and it’s now working as expected. I appreciate the effort you put into building this great platform, and we look forward to using it more.

[pglombardo]

That's great to hear @shnsys and thanks for the nice words! I'll update here again once I have some updates on this feature request.