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.

Sign up for GitHub

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

Jump to bottom

Improve email template in postmark to include location information from CF headers, agent information and validation phrase #347

Closed
2 of 6 tasks
Tracked by #220
hugomrdias opened this issue Jan 16, 2023 · 3 comments
Closed
2 of 6 tasks
Tracked by #220

Improve email template in postmark to include location information from CF headers, agent information and validation phrase #347

hugomrdias opened this issue Jan 16, 2023 · 3 comments
Assignees
@travis
Milestone
w3up phase 4

Comments

@hugomrdias
Copy link
Contributor

hugomrdias commented Jan 16, 2023 •
edited by travis
Loading

More context for this issue here https://purrfect-tracker-45c.notion.site/Email-auth-flow-d33f0715024a47c18a8114ba284e9c07
Example:
Screenshot 2023-01-12 at 16 44 58

Email should include:

  • Location info
  • Agent information
  • Validation phrase (generate in the backend)
  • Validation phrase should be printed in the agent requesting the email flow
  • Copy template to GH repo and maintain there (manual copy-paste to Postmark)
    • check if postmark supports templates in github instead of theirs dashboard.
@hugomrdias hugomrdias mentioned this issue Jan 16, 2023
Closed
95 tasks
@hugomrdias hugomrdias added this to the w3up phase 2 milestone Jan 16, 2023
This was referenced Jan 27, 2023
Closed
Open
@natevw
Copy link
Contributor

natevw commented Jan 27, 2023 •
edited
Loading

The work in #399 should resolve the second half of your checklist:

  • Location info
  • Agent information
  • Validation phrase (generate in the backend)
  • Validation phrase should be printed in the agent requesting the email flow
  • Copy template to GH repo and maintain there (manual copy-paste to Postmark)
    check if postmark supports templates in github instead of theirs dashboard.

Although the "printed in the agent" part is mostly on the w3ui side tracked as storacha/w3ui#307, the changes on the API shouldn't break the protocol. (The user would just have to click the approve link without being able to see the phrase in the client yet, or maybe simply let API generate the phrase but wait on publishing the actual Postmark template changes until UI is ready.)

@hugomrdias hugomrdias removed their assignment Feb 7, 2023
@travis travis self-assigned this Feb 8, 2023
@travis travis mentioned this issue Feb 9, 2023
Closed
8 tasks
@heyjay44 heyjay44 mentioned this issue Feb 9, 2023
Closed
83 tasks
@heyjay44 heyjay44 modified the milestones: w3up phase 2, w3up phase 3 Feb 9, 2023
travis added a commit to storacha/ucanto that referenced this issue Feb 20, 2023
@travis
proposal: add a bag of string-keyed key/value pairs to invocation con…
bfcc80a 
…text

As part of storacha/w3up#347 I'm looking into making
location information from CloudFlare HTTP headers available
to the invocation handler that generates emails (https://github.com/web3-storage/w3protocol/blob/main/packages/access-api/src/service/voucher-claim.js#L45) so
that we can tell users where in the world a space registration request was
initiated. This is a common pattern in web services and is intended to help the user
make better choices about which verification requests to approve.

To do this, we need some way of making HTTP headers available to invocation
handlers. I'd like to do this without tying the InvocationContext too tightly to HTTP,
and the simplest thing I can think of is adding a bag of string-keyed key/value
pairs named `metadata` to InvocationContext.

Very open to other approaches here - this is intended to be the starting point for a conversation.

One note worth bringing up for clarity - this opens the door to invocation handlers
doing all sorts of things with information from the HTTP headers, some of which
could conceivably be a violation of a user's privacy. It may be worth implementing
some sort of allow-list mechanism rather than just passing all HTTP headers through as
I'm doing in this PR. I'm not entirely sure where this
configuration would live, so am looking for thoughts and feedback.
@travis travis mentioned this issue Feb 20, 2023
Closed
@heyjay44
Copy link
Contributor

heyjay44 commented Mar 1, 2023

New PR is here: #432

@heyjay44 heyjay44 mentioned this issue Mar 27, 2023
Closed
23 tasks
@heyjay44 heyjay44 modified the milestones: w3up phase 3, w3up phase 4 Mar 27, 2023
@heyjay44
Copy link
Contributor

I'm creating a new issue to reflect our needs better.

@travis travis mentioned this issue Apr 11, 2023
Draft
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@travis travis

Labels
None yet
Projects
None yet
Milestone
w3up phase 4
Development

No branches or pull requests
4 participants
@travis @natevw @hugomrdias @heyjay44