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

What type of equality checking is being performed for options. #275

Closed
stevenatkin opened this issue Jun 29, 2017 · 2 comments
Closed

What type of equality checking is being performed for options. #275

stevenatkin opened this issue Jun 29, 2017 · 2 comments

Comments

@stevenatkin
Copy link

@stevenatkin stevenatkin commented Jun 29, 2017

  1. PushManager interface
    https://www.w3.org/TR/push-api/#pushmanager-interface

In step 10.4 it states that the option values need to be compared for equality. What type of equality checking is being performed? The options argument seems to be either a BufferSource or a DOMString. So are you using byte equality when it is a BufferSource vs. some other type of equality checking when it is a DOMString?

@beverloo

This comment has been minimized.

Copy link
Member

@beverloo beverloo commented Aug 21, 2017

The options attribute is an instance of PushSubcriptionsOptionsInit, which has the applicationServerKey member that you're referring to. Our intent with the phrasing of 8.10.4. is to avoid repeating the individual members of PushSubscriptionOptions.

When the developer passes a DOMString, step 8.4.1. converts it to a BufferSource, but we don't write it back to options. That means that step 8.10.4. would still use the DOMString, and would thus fail.

I'm not sure what the cleanest way of fixing this is. Changing 8.4. to the following may work?

  1. If the applicationServerKey is provided as a DOMString, set its value to a BufferSource containing the sequence of octets that result from decoding applicationServerKey using the base64url encoding [RFC7515]. If decoding fails, reject promise with a DOMException whose name is "InvalidCharacterError" and terminate these steps.
  2. Ensure that the applicationServerKey describes a valid point on the P-256 curve. If the applicationServerKey value is invalid, reject promise with a DOMException whose name is "InvalidAccessError" and terminate these steps.

What do you think, @martinthomson?

@martinthomson

This comment has been minimized.

Copy link
Member

@martinthomson martinthomson commented Aug 22, 2017

That would be fine. It means writing to options, which isn't ideal, but it's an elegant solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.