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

Research and avoid SafeLinks and other auto open email client stuff #348

Closed
1 task done
Tracked by #220
hugomrdias opened this issue Jan 16, 2023 · 0 comments
Closed
1 task done
Tracked by #220

Research and avoid SafeLinks and other auto open email client stuff #348

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

Comments

@hugomrdias
Copy link
Contributor

hugomrdias commented Jan 16, 2023 •
edited by travis
Loading

More context here https://purrfect-tracker-45c.notion.site/Email-auth-flow-d33f0715024a47c18a8114ba284e9c07

  • Make the current response page run javascript that triggers the websocket, this way only http client that can run javascript will start the websocket to send the delegation back automatically

The email html source in the notion document has what looks like counter measures for this.
@hugomrdias hugomrdias mentioned this issue Jan 16, 2023
Closed
95 tasks
@hugomrdias hugomrdias changed the title Research and avoid [SafeLinks](https://stackoverflow.com/questions/62108517/clicking-outlook-safelink-protection-links-in-emails-seems-to-be-executing-the-c/65095191#65095191) and other auto open email client stuff Research and avoid SafeLinks and other auto open email client stuff Jan 16, 2023
nate-dag pushed a commit to natevw/w3protocol that referenced this issue Jan 27, 2023
@natevw
fix: avoid email delegation via GET request
02c40bf 
the email validation approval process is now split into two stages: a GET request with no side effects except to load a page that then auto-submits a POST request to actually continue the flow. this fixes the API to follow proper API semantics and thus starts addressing some of storacha#333 and presumably fixes all of storacha#348
This was referenced Jan 27, 2023
Closed
Open
@travis travis self-assigned this Feb 8, 2023
travis pushed a commit that referenced this issue Feb 9, 2023
@natevw @travis
fix: avoid email delegation via GET request
2cacaaf 
the email validation approval process is now split into two stages: a GET request with no side effects except to load a page that then auto-submits a POST request to actually continue the flow. this fixes the API to follow proper API semantics and thus starts addressing some of #333 and presumably fixes all of #348
@travis travis mentioned this issue Feb 9, 2023
Merged
@heyjay44 heyjay44 mentioned this issue Feb 9, 2023
Closed
83 tasks
@heyjay44 heyjay44 added this to the w3up phase 3 milestone Feb 9, 2023
travis added a commit that referenced this issue Feb 10, 2023
@travis @natevw
fix: avoid email delegation via GET request (#430)
d282d6a 
The email validation approval process is now split into two stages: a
GET request with no side effects except to load a page, that then
auto-submits a POST request to actually continue the flow.

## Summary of problem

This fixes the API so as to follow [proper HTTP
semantics](#333 (comment)):

> The purpose of distinguishing between safe [i.e. like GET] and unsafe
[like PUT/POST] methods is to allow automated retrieval processes
(spiders) and cache performance optimization (pre-fetching) to work
without fear of causing harm. In addition, it allows a user agent to
apply appropriate constraints on the automated use of unsafe methods
when processing potentially untrusted content.

That is, a `PUT` or `POST` (rather than a `GET`) **must** be the method
used in order to do things like

* cause a message to be sent (forwarding a UCAN delegation via a
separate connection's websocket)
* cause an untrusted keypair to be associated with a billable email
address (which is the outcome of that forwarding, in practice!)

Fixing the HTTP semantics should address all of #348, and is the first
step to addressing the security concerns in #333.

## Summary of solution

Clicking (or scanning/pre-fetching/previewing/etc.) the link in the
email no longer finishes the validation process. Instead, it loads a
(harmless to scan/pre-fetch/preview) landing page which simply says
"Validating Email" while using JavaScript to auto-complete the process.

This patch is able to fix the core HTTP semantics in a very self-contained way:

* no changes needed to the email templates
* will not break any existing unexpired links at the moment it is
deployed
* is essentially the exact same UX from a user's perspective (they might
notice just a little extra blink)
* does degrade gracefully if user has JS disabled, and any non-browser
clients could still trigger the `POST` ± just as easy as before
* no changes needed on the `w3ui` side for this part of the email
validation improvements

---------

Co-authored-by: Nathan Vander Wilt <[email protected]>
gobengo pushed a commit that referenced this issue Apr 11, 2023
@travis @natevw
fix: avoid email delegation via GET request (#430)
e0f67e8 
The email validation approval process is now split into two stages: a
GET request with no side effects except to load a page, that then
auto-submits a POST request to actually continue the flow.

## Summary of problem

This fixes the API so as to follow [proper HTTP
semantics](#333 (comment)):

> The purpose of distinguishing between safe [i.e. like GET] and unsafe
[like PUT/POST] methods is to allow automated retrieval processes
(spiders) and cache performance optimization (pre-fetching) to work
without fear of causing harm. In addition, it allows a user agent to
apply appropriate constraints on the automated use of unsafe methods
when processing potentially untrusted content.

That is, a `PUT` or `POST` (rather than a `GET`) **must** be the method
used in order to do things like

* cause a message to be sent (forwarding a UCAN delegation via a
separate connection's websocket)
* cause an untrusted keypair to be associated with a billable email
address (which is the outcome of that forwarding, in practice!)

Fixing the HTTP semantics should address all of #348, and is the first
step to addressing the security concerns in #333.

## Summary of solution

Clicking (or scanning/pre-fetching/previewing/etc.) the link in the
email no longer finishes the validation process. Instead, it loads a
(harmless to scan/pre-fetch/preview) landing page which simply says
"Validating Email" while using JavaScript to auto-complete the process.

This patch is able to fix the core HTTP semantics in a very self-contained way:

* no changes needed to the email templates
* will not break any existing unexpired links at the moment it is
deployed
* is essentially the exact same UX from a user's perspective (they might
notice just a little extra blink)
* does degrade gracefully if user has JS disabled, and any non-browser
clients could still trigger the `POST` ± just as easy as before
* no changes needed on the `w3ui` side for this part of the email
validation improvements

---------

Co-authored-by: Nathan Vander Wilt <[email protected]>
Peeja pushed a commit to storacha/upload-service that referenced this issue Jan 17, 2025
@travis
fix: add registry-url and cache config to github actions setup-node (s…
56a687b 
…toracha#348)

Cutting a new release earlier today failed. Fortunately @alanshaw and
@olizilla noticed that our working w3protocol builds have two extra
lines of relevant config, one of which seems to be the culprit:

> @alanshaw
> Only difference I can see is with w3ui and w3protocol is that
setup-node in w3protocol sets cache: pnpm and registry-url:
'https://registry.npmjs.org'
https://github.com/web3-storage/w3protocol/blob/4d72ba3a1ce2564cda13c62137967613b18334a7/.github/workflows/release.yml#L47-L48
which is not being set here:
https://github.com/web3-storage/w3ui/blob/0c661c6f4d28776b4ac7ad1aea3e0958186f8480/.github/actions/pnpm/action.yml#L7-L9

> olizilla
> it looks like registry-url must be set for setup-node to configure npm
with an auth token:
https://github.com/actions/setup-node/blob/ae9f0f7448e93b1be0f44663e79763dbdffcc4da/src/main.ts#L56-L60

add these lines and pray to the release gods!
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 3
Development

No branches or pull requests
3 participants
@travis @hugomrdias @heyjay44