search

w3c / push-api

Push API
https://w3c.github.io/push-api/
Other
146 stars 40 forks source link

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

Closed stevenatkin closed 6 years ago

stevenatkin commented 7 years ago
  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 commented 7 years ago

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 commented 7 years ago

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