Not only having the token in the callback URL is more elegant than having it this extra param, but it makes the token available when the ping is received.
This is nice because matching a ping content to a subscription is not always easy for the subscriber (the link.self is often missing or broken) Also, it can enable pubsubhubbub to carry any kind of content, not just feed data. Antoine On Mon, Feb 20, 2012 at 8:22 AM, Julien Genestoux <[email protected]> wrote: > Andy, > > The only way to "secure" communication upon subscription is to use https on > the hub. By doing so, the subscriber can very well check that it's talking > to the right hub, and none can then intercept that. Using (or not) > verify_token doesn't change anything. > > verify_token does not have any "security" role here and won't prevent any > attack whatsoever. > > It's only purpose is/was to help subscriber match a subscription faster with > a given feed, should they receive 2 verification of intent concurrently. > > Now, this can very well be done with the callback and I would argue that > this is actually more elegant than using an extra param. > > An easy way to make that change backward compatible is just to specify that > any additional POST param sent along the subscription should be used in the > GET verification of intent. > > Julien > > > On Mon, Feb 20, 2012 at 4:06 PM, Andy Dennie <[email protected]> > wrote: >> >> I tried to reply to this a while back, but my comment didn't go through, >> so I'm trying again. My understanding of the verify_token is that it >> allows the subscriber to confirm that the subscription verification request >> is coming from the hub to which the subscription request was sent, and not >> an imposter. Assuming the subscription request is sent to the hub using >> HTTPS, the value of the verify_token is hidden from wire snoopers. >> Therefore, its presence in the verification request to the callback proves >> that the sender of that request is the same hub to which the subscription >> request was sent. The value of the verify_token could be sniffed off the >> verification request, but since it is a one-time-use value, it could not be >> used again by an imposter. >> >> I do see that putting an equivalent value into the callback URL via a >> query parameter would have the same mechanics of being encrypted in an HTTPS >> subscription request and being visible in a subscription verification >> request, and it still could be treated in a one-time-use way by the >> subscriber (i.e. discard the value after the first verification, so that a >> subsequent verification request from an imposter would be rejected) . But >> somewhat inelegantly, it would need to be supplied on all future callback >> requests (i.e. content distribution), instead of just the subscription >> verification request, even though it would be no longer of value. > >
