If the hub.verify_token is maintained as a query parameter, it would seem
that the complexity of the protocol isn't changed. The token is still
there, just in a different place. However, there is a new problem in that
it becomes necessary to distinguish between query parameters that pass
information specific to the PSHB protocol and those that may be part of the
feed URL.

What problem does hub.verify_token create and how would moving it to be a
query parameter solve that problem? Can you say more about the motivation
for removing it?

Moving this data from its current position as a post parameter to a query
parameter will tend to make it more public. Most web traffic logging
systems log URLs visited (including query parameters) while post parameters
are less frequently logged. If the hub.verify_token becomes a query
parameter, it is likely that this token, which is presumably something that
subscribers wish to be "secret," will be more often logged. Is this a good
thing?

bob wyman


On Sun, Nov 20, 2011 at 11:11 AM, Monica Wilkinson
<[email protected]>wrote:

> So this appears to be a breaking change... Is a possible workaround for
> subscribers to say that the callback url includes a query string parameter
> "hub.verify_token"
>
>
> On Sun, Nov 20, 2011 at 6:32 AM, Julien Genestoux <
> [email protected]> wrote:
>
>> All,
>>
>> In the process of "cleaning" up the spec and to make it ready to add more
>> important coverage (arbitrary format, private feeds), I identified that we
>> should probably remove the "hub.verify_token".
>>
>> I'm not completely sure why it was initially added (Brett, Brad, Mart?),
>> but I think it was to facilitate the matching of a feed and subscription
>> for the subscriber who gets a verification of intent request. I believe
>> this can all be done thru the callback url, which (as per the good
>> practices) should be different for each subscription/feed.
>>
>> I'm not sure how to submit changes to the protocol, but this would affect
>> the following sections :
>> 6.1 : Removal of :
>>
>>> hub.verify_token
>>> OPTIONAL. A subscriber-provided opaque token that will be echoed back in
>>> the verification request to assist the subscriber in identifying which
>>> subscription request is being verified. If this is not included, no token
>>> will be included in the verification request.
>>
>> 6.2 : Removal of :
>>
>>> hub.verify_token
>>> OPTIONAL. The subscriber-provided opaque token from the corresponding
>>> subscription request, if one was provided.
>>
>> 6.2.1 Change of the first paragraph (remove the red):
>>
>>>  The subscriber MUST confirm that the hub.topic and hub.verify_token 
>>> correspond
>>> to a pending subscription or unsubscription that it wishes to carry out.
>>> [...]
>>
>> 8.2 : Removal of section altogether.
>>
>> Feedback?
>>
>> Thanks!
>>
>
>

Reply via email to