Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Users can use Notify to send emails to participants #109

Closed
jonodrew opened this issue Aug 15, 2022 · 10 comments · Fixed by #114
Closed

Users can use Notify to send emails to participants #109

jonodrew opened this issue Aug 15, 2022 · 10 comments · Fixed by #114
Assignees

Comments

@jonodrew
Copy link
Owner

jonodrew commented Aug 15, 2022

Users should be able to use Notify to send the results out

Not in scope: other mailing platforms

@jonodrew
Copy link
Owner Author

This is being worked on with #104

@jonodrew jonodrew linked a pull request Aug 15, 2022 that will close this issue
@jonodrew
Copy link
Owner Author

Key question for me here is: how to secure the key that we're given.

  • we need https, to secure the connection to the remote server
  • we should encrypt the secret in transit

@jonodrew jonodrew self-assigned this Aug 21, 2022
@jonodrew
Copy link
Owner Author

Encrypting the API key and putting it in the cookie would enable us to generate a preview of the email(s), but carries risks:

  • if the server's SECRET_KEY is exposed, any cookie that has the encrypted API key is at risk
  • if the server's SECRET_KEY is insufficiently secure, any cookie that has the encrypted API key is at risk
  • anyone capturing the cookie can use it to spam the participants until the output files are deleted (ie send millions of requests). This would doubtless get us banned from using Notify

I'd rather treat this like a credit card number: have the user put it in directly at the point it'll be used, and never let it anywhere near the cookie. However, this does mean that we can't generate a preview.

@jonodrew
Copy link
Owner Author

I think this also means we need some content at the front of the service that says


Integration with Notify

This service is integrated with Notify. If you'd like to use Notify, you'll need an API key. So that we don't keep your API key for any longer than necessary, you won't get a chance to preview your messages before they're sent. We recommend that you test your Notify templates with an [example output file](link to an example file)


We can replicate it in the Notify journey, but I really don't want users to get to the end, with the clock ticking, and realise they can't even test it.

The other option is to get users to also grab a test key from Notify, which we can use in a cookie because it can't send emails but it can create previews. Any thoughts @johnpeart ?

@johnpeart
Copy link
Collaborator

johnpeart commented Aug 22, 2022

I agree with you – let's treat this as a high-risk scenario. If showing previews increases the attack surface for a data breach, let's not increase the size of the surface!

The test key route feels like a nice additional touch, but it feels like gold plating right now that will add further complication to a UI that is already complicated because of needing to provide 6 keys and ID codes already.

So let's add the additional text! Where do you think we should add it? On the start page?

We could also add default templates for Notify to the docs; I can pick this up as part of #113.

@jonodrew
Copy link
Owner Author

Yes, I think the start page is best. I've put some content on a new page as a starter - we can drop that page once the whole journey is clearer.

The other outstanding question is how we get from the matching workflow to the notification workflow. At the moment, if you download the matches the system auto-deletes them. However, I think the addition of the notification workflow means some users will want to download the matches, check they're happy with the proposed selections, and then send them. We should be able to meet this user need, while also continuing to delete matches where users are finishing their journey.

We could:

  • apply the "delete in x minutes" pattern, whether the user downloads the matches or not <- my preferred
  • have something in the interface that asks if a user is downloading to preview or end their journey, and then acts accordingly

jonodrew added a commit that referenced this issue Aug 22, 2022
@johnpeart
Copy link
Collaborator

The other outstanding question is how we get from the matching workflow to the notification workflow. At the moment, if you download the matches the system auto-deletes them. However, I think the addition of the notification workflow means some users will want to download the matches, check they're happy with the proposed selections, and then send them. We should be able to meet this user need, while also continuing to delete matches where users are finishing their journey.

We could:

  • apply the "delete in x minutes" pattern, whether the user downloads the matches or not <- my preferred
  • have something in the interface that asks if a user is downloading to preview or end their journey, and then acts accordingly

We should discuss this – is there another issue on this yet or shall I create one?

@jonodrew
Copy link
Owner Author

Needs a new issue I think. Would you mind creating one?

@jonodrew
Copy link
Owner Author

New issue: #115

@johnpeart
Copy link
Collaborator

You beat me to it!
Sorry – I am not as on top of my Github notifications as you (probably by virtue of not being in Github for the day job!)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging a pull request may close this issue.

2 participants