But do we actually need to know the difference between the params in the callback url and the ones added by the hub? Not really. Right now the subscriber can very well add kind of query string param, and they should be preserved by the hub anyway.
The hub.verify_token doesn't create any problem, except that it doesn't solve any problem that is not solvable via a more elegant way (the callback url). I think it adds complexity to the spec and implementation... As for moving it from a POST to a GET, I beg to differ :) It's a POST param in the subscription request... If we remove it, it becomes a query string param to a POST request (I understand this isn't fully HTTP-spirit compliant but that works quite well). It is already a GET param in the verification of intent (from the hub to the susbcriber), and will stay as such. I understand the idea of "secrecy", but I think it is also very dangerous to let people think that this may in any way make anything secure. I'd rather ask people use the actual secret mechanism by not leaving any doubt that something else may make their subscriptions secure. Julien On Sun, Nov 20, 2011 at 10:36 PM, Bob Wyman <[email protected]> wrote: > 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! >>> >> >> >
