Concept behind verify token
Julien Genestoux
I am having a debate with one of superfeedr's hub user about the goal
of the verify token.
Basically I think it should be removed from the spec because I don't
see it's purpose, please prove me wrong.
Julien
-
Julien Genestoux
julien.g...@gmail.com
+1 (415) 254-7340
http://www.ouvre-boite.com
Envoyé depuis mon iPhone
Martin Atkins
>
> Hi!
>
> I am having a debate with one of superfeedr's hub user about the goal of
> the verify token.
>
> Basically I think it should be removed from the spec because I don't see
> it's purpose, please prove me wrong.
>
The verify token is there to ensure that the endpoint really is a
PubSubHubbub endpoint and not just something that returns a 200 OK
response, which obviously applies to lots of things on the web that are
not Hubbub endpoints.
Julien Genestoux
supposed to query the subscriber ton confirm subscription, I guess it
isn't really needed, is it?
--
Julien Genestoux
julien.g...@gmail.com
+1 (415) 254-7340
http://www.ouvre-boite.com
Envoyé depuis mon iPhone
On Sep 28, 2009, at 16:32, Martin Atkins <ma...@degeneration.co.uk>
wrote:
Julien Genestoux
subscriber, right? And then used by the hub in the verification part?
So, I am still not sure why it is needed?
The hub will return 200 only if the subscriber echoes the challenge...
So the presence (or not) of the token shouldn't change anything, right?
Or is that that the hub should echo the token upon succesul
subscripion/unsubscription?
I guess all that means that the hub doesn't need to store the token,
does it?
--
Julien Genestoux
julien.g...@gmail.com
+1 (415) 254-7340
http://www.ouvre-boite.com
Envoyé depuis mon iPhone
On Sep 28, 2009, at 16:32, Martin Atkins <ma...@degeneration.co.uk>
wrote:
>
Brett Slatkin
On Mon, Sep 28, 2009 at 3:40 PM, Julien Genestoux
<julien.g...@gmail.com> wrote:
>
> Ha ok, I see... I never thought about that... But since the hub is supposed
> to query the subscriber ton confirm subscription, I guess it isn't really
> needed, is it?
The verify_token is an opaque handle, supplied from the subscriber to
the hub, used for two things:
1. Verify that the subscription request is coming from the Hub who the
subscriber just contacted.
One attack is a rogue hub could know the callback URL for a subscriber
and sign it up for subscriptions it doesn't want. The verify_token
gives the subscriber a way to make sure that it was actually their
request that initiated the subscription for the given topic (i.e., the
tuple (topic, verify_token) is correct).
Why do we need the verify_token then? Someone requested that we put
the Hub's URL in the subscription request instead
(http://code.google.com/p/pubsubhubbub/issues/detail?id=42).
2. Using a token here gets around the myriad of name-aliasing issues
that could crop up if we did this.
For example, you may advertise your hub as
http://hub.example.com/~mypath/hub, but it may be reachable on a
variety of aliases (http://hub.example.com/publish,
http://hub.example.com/%7Emypath/hub, etc). You also may move the hub
(and change it's address) between the time the subscription was made
and the subscription is auto-renewed (following
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#autorefresh).
Well, why can't the user just encode their own token in a query-string
parameter for each subscription and verify it that way?
3. Using a token parameter allows multiple topics with the same
callback URL to be aggregated for efficiency (following
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#aggregatedistribution).
We do not want the hub to understand the semantics of any callback-URL
query string parameters because this is difficult to express,
implement, and define in the spec. So the verify_token forces us to
have a single communal value with understood semantics that can be
used in this way.
It seems to me we should clarify the role of the verify_token
(probably in this issue:
http://code.google.com/p/pubsubhubbub/issues/detail?id=57) and provide
more guidance on how to use it as a subscriber.
Let me know if that all makes sense!
-Brett
Martin Atkins
>
> Wait... I replied too fast... The verify token is supplied by the
> subscriber, right? And then used by the hub in the verification part?
> So, I am still not sure why it is needed?
>
I'm sorry. I was thinking of the wrong token. I was thinking of the
"challenge" on the verify request.
The verify_token is optional, so if the subscriber is able to verify the
subscription based on the topic URL alone then it need not be included.
I assume it's there for subscribers who can more quickly check the
validity of a subscription by looking up some data store id than by
looking up by URL.
For example, if I send out a pending subscription I might create a
subscription row in my datastore which has the (possibly large) URL as a
non-indexed property, then use the table's numeric PK as the
verify_token since its length is predictable and I can use it without
fear of blowing up my indexes or my memcache keys.
Julien Genestoux
--
Julien Genestoux
julien.g...@gmail.com
+1 (415) 254-7340
http://www.ouvre-boite.com
Envoyé depuis mon iPhone
On Sep 28, 2009, at 16:59, Brett Slatkin <bsla...@gmail.com> wrote:
>
> Hey Julien,
>
> On Mon, Sep 28, 2009 at 3:40 PM, Julien Genestoux
> <julien.g...@gmail.com> wrote:
>>
>> Ha ok, I see... I never thought about that... But since the hub is
>> supposed
>> to query the subscriber ton confirm subscription, I guess it isn't
>> really
>> needed, is it?
>
> The verify_token is an opaque handle, supplied from the subscriber to
> the hub, used for two things:
>
>
> 1. Verify that the subscription request is coming from the Hub who the
> subscriber just contacted.
>
> One attack is a rogue hub could know the callback URL for a subscriber
> and sign it up for subscriptions it doesn't want.
I see... But i thought it was the subscribers responsability to make
sure his callback(s) where kept secret... I mean assuming that there
might exist rogue hub is just assuming that someone "guessed" a
subscriber callback URL? So I think itthe same problem as anybody
pinging a subscriber?why a different solution?
Also couldnt This be done withh http get params in The callback URL?
Wouldnt that be simpler? The subsccriber would be in charge of his urls?
> The verify_token
> gives the subscriber a way to make sure that it was actually their
> request that initiated the subscription for the given topic (i.e., the
> tuple (topic, verify_token) is correct).
>
>
> Why do we need the verify_token then? Someone requested that we put
> the Hub's URL in the subscription request instead
> (http://code.google.com/p/pubsubhubbub/issues/detail?id=42).
>
>
> 2. Using a token here gets around the myriad of name-aliasing issues
> that could crop up if we did this.
>
> For example, you may advertise your hub as
> http://hub.example.com/~mypath/hub, but it may be reachable on a
> variety of aliases (http://hub.example.com/publish,
> http://hub.example.com/%7Emypath/hub, etc). You also may move the hub
> (and change it's address) between the time the subscription was made
> and the subscription is auto-renewed (following
> http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#autorefresh
> ).
Indeed I dontthunj the hubs URL is a good solution.
>
>
> Well, why can't the user just encode their own token in a query-string
> parameter for each subscription and verify it that way?
>
>
>
> 3. Using a token parameter allows multiple topics with the same
> callback URL to be aggregated for efficiency (following
> http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#aggregatedistribution
> ).
Ha, you anticipated my question;) but that makes sense if we need that
verfy token, but I am still not sure the protocol needs it... It
confused a lot one of our users... And i am afraid it might confuse
more people.
>
> We do not want the hub to understand the semantics of any callback-URL
> query string parameters because this is difficult to express,
> implement, and define in the spec. So the verify_token forces us to
> have a single communal value with understood semantics that can be
> used in this way.
>
>
>
> It seems to me we should clarify the role of the verify_token
> (probably in this issue:
> http://code.google.com/p/pubsubhubbub/issues/detail?id=57) and provide
> more guidance on how to use it as a subscriber.
>
> Let me know if that all makes sense!
>
It does... But I still think it's not needed ;)
Anyhoo, clarification in the spec would be appreciated!
Thx for your time!
Julien Genestoux
--
Julien Genestoux
julien.g...@gmail.com
+1 (415) 254-7340
http://www.ouvre-boite.com
Envoyé depuis mon iPhone
On Sep 28, 2009, at 17:00, Martin Atkins <ma...@degeneration.co.uk>
wrote:
>
> Julien Genestoux wrote:
>> Wait... I replied too fast... The verify token is supplied by the
>> subscriber, right? And then used by the hub in the verification
>> part? So, I am still not sure why it is needed?
>
> I'm sorry. I was thinking of the wrong token. I was thinking of the
> "challenge" on the verify request.
>
> The verify_token is optional, so if the subscriber is able to verify
> the subscription based on the topic URL alone then it need not be
> included. I assume it's there for subscribers who can more quickly
> check the validity of a subscription by looking up some data store
> id than by looking up by URL.
That is what I initially assumed... But then found out it can be done
via any query string param... So why explicitly adding something
optional that is duplicating something else?
Martin Atkins
>
> That is what I initially assumed... But then found out it can be done
> via any query string param... So why explicitly adding something
> optional that is duplicating something else?
>>
As Brett said, having it in the query string means it's no longer
possible for the hub to batch together notifications about different
topics into a single ping, since each of them would have a different
subscriber URL.