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

Add support for merchant validation #751

Merged
merged 11 commits into from
Aug 30, 2018
Merged

Conversation

marcoscaceres
Copy link
Member

@marcoscaceres marcoscaceres commented Jul 6, 2018

closes #646

The following tasks have been completed:

Implementation commitment:

Impact on Payment Handler spec?


Preview | Diff

@marcoscaceres marcoscaceres requested a review from aestes July 6, 2018 21:41
@marcoscaceres marcoscaceres changed the title Merchantvalidation Add support for merchant validation Jul 6, 2018
@marcoscaceres
Copy link
Member Author

Blocking on @aestes review/feedback. This is primarily to align with Apple Pay so really need someone from Apple to approve it.

@marcoscaceres
Copy link
Member Author

@marcoscaceres
Copy link
Member Author

index.html Outdated
Validate a merchant algorithm
</h2>
<p>
<dfn>Merchant validation</dfn> is the process by which <a>payment
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two missing a's

<dfn>Merchant validation</dfn> is the process by which a <a>payment
          handler</a> validates the identity of a merchant.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@marcoscaceres
Copy link
Member Author

Added tests for constructor and for onmerchantvalidation attribute:
web-platform-tests/wpt#12424 and web-platform-tests/wpt#12423

Copy link
Collaborator

@aestes aestes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, although I was surprised to see that MerchantValidationEvent.validationURL can be initialized from the eventInitDict. Is that there for payment handlers' sake?

@marcoscaceres
Copy link
Member Author

@aestes, wrote:

This looks good, although I was surprised to see that MerchantValidationEvent.validationURL can be initialized from the eventInitDict. Is that there for payment handlers' sake?

It's not handler related - but could be used there too, I guess: It used to be a requirement in the DOM Spec that there be a 1:1 relationship between initialization dictionary members and Event interface attributes.

@domenic, I see this has now changed in the inner event creation steps. It seems that requirement was loosened up a bit:

For each member → value in dictionary, if event has an attribute whose identifier is member, then initialize that attribute to value.

Or does the 1:1 relationship rule still hold?

@aestes, the .complete() still rely on .isTrusted - so IMO it would still be good to define how URLs are resolved when the MerchantValidationEvent is constructed (even if constructed unsafely in JS).

@marcoscaceres
Copy link
Member Author

@domenic requesting prioritization on this when you have time, as currently I'm working on an implementation in Gecko - so would really appreciate your review.

@domenic
Copy link
Collaborator

domenic commented Aug 21, 2018

The idea is still to have 1:1, but there are a few legacy exceptions we worked to accomodate with that clause.

Will do a full review tomorrow!

Copy link
Collaborator

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall makes sense; some things to fix

index.html Outdated
"MerchantValidationEvent.MerchantValidationEvent()"><code>MerchantValidationEvent</code>
Constructor</dfn>
</h3>
<p data-tests=
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be new technology since we last worked on this, but now we have https://dom.spec.whatwg.org/#concept-event-constructor-ext. You should define "event constructing steps" for MerchantValidationEvent which:

  • set [[waitForUpdate]] etc.
  • Validate/normalize/set the default for the validationURL attribute (no internal slot for event attributes).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new machinery took me a little bit to get going... but it's much nicer 👌 Will eventually need to update the rest of the spec to use it.

index.html Outdated
Constructor</dfn>
</h3>
<p data-tests=
"MerchantValidationEvent/constructor.https.html, MerchantValidationEvent/constructor.http.html">
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The internal slots list, both in the constructor and in the table, seem incomplete. The constructor initializes waitForUpdate and validationURL. (validationURL should not be an internal slot.) The table lists request and validationURL. The complete() method operates on request and waitForUpdate.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, copy/pasta. I've added a [[waitForUpdate]] slot and linked it properly. validationURL is now set on the attribute, not a slot.

index.html Outdated
<ol class="algorithm">
<li>Let <var>base</var> be the <a data-cite=
"dom#context-object">context object</a>’s <a data-cite=
"!html/multipage/webappapis.html#relevant-settings-object">relevant
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no context object in constructors. But once you use event constructing steps you can use event's relevant settings object.

index.html Outdated
</td>
<td>
The <a>PaymentRequest</a> instance that instantiated this
<a>PaymentResponse</a>.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"this" is not a PaymentResponse, so this doesn't seem right...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These slots are not needed anymore. I can get request from target, after isTrusted is checked.

index.html Outdated
</li>
<li>Set <var>event</var>.<a>[[\waitForUpdate]]</a> to true.
</li>
<li>Run the <a>validate a merchant algorithm</a> with
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wrong algorithm

Copy link
Member Author

@marcoscaceres marcoscaceres Aug 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh crap. I went all circular (how embarrassing!)... this was supposed to:

  1. disable the UI.
  2. wait for the promise to settle, "abort the update" is it rejects...
  3. if it fulfills, then value needs to be cryptographically verified.
  4. if the merchant is no good, abort the update.
  5. if merchant is validated, enable the UI.

index.html Outdated
<p>
For <a>payment methods</a> that support <a>merchant validation</a>,
the user agent runs the <dfn>validate a merchant algorithm</dfn>. The
algorithm takes a USVString <var>merchantSpecificURL</var>, provided
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either link/code-ify USVString or use scalar value string.

index.html Outdated
<li>Otherwise, set <var>request</var>.<a>[[\updating]]</a> to
false.
</li>
<li>Enable user interface, allowing the request for payment to
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing "the"

@marcoscaceres
Copy link
Member Author

@domenic, hopefully better now :/

Copy link
Collaborator

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only a couple more minor things

index.html Outdated
<h3>
<dfn data-lt=
"MerchantValidationEvent.MerchantValidationEvent()"><code>MerchantValidationEvent</code>
Constructor</dfn>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lowercase "c"

index.html Outdated
<p data-tests=
"MerchantValidationEvent/constructor.https.html, MerchantValidationEvent/constructor.http.html">
The <dfn>event constructing steps for a
<code>MerchantValidationEvent</code></dfn>, which take a
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to link to "event constructing steps" in DOM, not define a new set of steps.

<var>base</var>.
</li>
<li>If <var>validationURL</var> is failure, throw a
<a>TypeError</a>.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to initialize event's validationURL attribute to validationURL

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

D'oh! Added just below.

index.html Outdated
<li>Initialize <var>event</var>.<a data-lt=
"mechvalidation.waitForUpdate">[[\waitForUpdate]]</a> to false.
</li>
<li>Return <var>event</var>.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to return anything from these steps.

@marcoscaceres
Copy link
Member Author

Third time lucky 🤞

@marcoscaceres marcoscaceres merged commit 944f512 into gh-pages Aug 30, 2018
@marcoscaceres marcoscaceres deleted the merchantvalidation branch August 30, 2018 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for merchant validation
4 participants