hub.verify_token & hub.challenge

[Joseph Scott]

I've been reading through the verification portion of the PuSH spec -
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#verifysub
- and had a question about how hub.challenge and hub.verify_token are
handled. A portion of section 6.2.1 that talks about what the
notification end point sends back says:

----------------
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. If so, the subscriber MUST respond with an HTTP success
(2xx) code with a response body equal to the hub.challenge parameter.
If the subscriber does not agree with the action, the subscriber MUST
respond with a 404 "Not Found" response.
----------------

The way that I read that is that if the hub.challenge parameter is the
string "098uytfdsz" then the response body must be exactly that string
and only that string (because of the word 'equal' in the spec). My
question is, how is the hub.verify_token value supposed to be returned
if the response body can only be the value of hub.challenge?

[Brett Slatkin]

Hey Joseph,

There are two things going on here:

1. The subscriber sends hub.verify_token to the hub. The hub forwards
this back to the subscriber so the subscriber can verify the request
came from that hub and/or use the token as a handle to some internal
data structure. The hub.verify_token never has to be echoed back to
the hub for verification; it's optional and only used by subscribers
for convenience.

2. The hub sends the hub.challenge parameter to the subscriber to
verify the subscription. The subscriber must respond with that
challenge as the response body to validate the subscription.

Hope that helps,

-Brett

[Joseph Scott]

On Thu, Sep 17, 2009 at 12:19 AM, Brett Slatkin <bsla...@gmail.com> wrote:
> 1. The subscriber sends hub.verify_token to the hub. The hub forwards
> this back to the subscriber so the subscriber can verify the request
> came from that hub and/or use the token as a handle to some internal
> data structure. The hub.verify_token never has to be echoed back to
> the hub for verification; it's optional and only used by subscribers
> for convenience.

Okay, I think that clarifies things. When a hub sends out a
notification it can pass along a hub.verify_token value (if one was
provided by the original notification request) but doesn't expect it
to be provided back as part of the response.

>
> 2. The hub sends the hub.challenge parameter to the subscriber to
> verify the subscription. The subscriber must respond with that
> challenge as the response body to validate the subscription.

That part I got, my confusion came from the idea that hub.verify_token
(if one was provided) also had to be in the response. Since that
isn't the case my question is void I suppose.

--
Joseph Scott
jos...@josephscott.org
http://josephscott.org/