[pubsubhubbub] Re: Subscription verification

[Jay Rossiter]

On 10/15/2009 5:11 PM, Pádraic Brady wrote: >6.1.2 of the spec says "In synchronous mode, the verification (Section 6.2 (Hub Verifies Intent of the Subscriber)) MUST be completed >before the hub returns a response." It's important to note, as I noticed elsewhere recently, that we should avoid the assumption that synchronous and asynchronous support by Subscribers is a simple decision of one or the other. Subscribers may actually support both, and if so, should include the hub.verify parameter in their subscription request twice (one with a value of "sync", the other with a value of "async" - the order determines a soft preference). In this event, a Hub may soften the above rule so that even if they first attempt a synchronous verification which fails, if the Subscriber has a secondary asynchronous preference they can allow the request to complete successfully (as in async mode) and then attempt the application of 6.2.1. Note, this is not made clear in the specification but I think it's a solid approach. The final decision on what mode to persue is determined by the Hub - the Subscriber merely advertises a preference. This is another issue not highlighted in the specification. Superfeedr, for example, will return an error on any subscription request where the sole hub.verify parameter sent by a Subscriber equals "async" - Superfeedr do not support asynchronous verification. A bug fixed just recently will ignore the Subscriber's preference for asynchronous verification if they also include a synchronous preference (doesn't matter if it's first or second - just that it is supported).     This is already how I'm handling things - I just wanted to tighten up the language in the spec so that it was clear.  I support both verify methods, together, and individually.  What I was specifically referring to was the case where sync was specified, and async was not.  In that situation, I believe that it behaves as I outlined in the original email (unless anyone has a reason that it shouldn't).  The two portions of the spec contradict each other on this point.   The retry portion of 6.2.1, by definition, can only apply to async if the request "MUST be completed before the hub returns a response". >Also, a 200 reply with an incorrect challenge response should be considered immediately fatal and treated as if it was a 404 (in any verify >mode), correct?  (To help prevent DoS/spamming.) Absolutely. Discard it immediately. In returning the invalid challenge, technically the Subscriber probably also sent a 200 code as a definitive verification. They are therefore not expected to respond to a second verification request (from an implementation standpoint - it's probably moot but could be deliberately prevented to block duplicate requests of this kind). Since their final response is invalid you can simply abandon it. This is a bit tricky since it's possible it was simple error by a valid Subscriber - but since it is a security measure no further action should be required. It's the Subscriber's responsibility to run a bug free Subscriber.     Again - already how I'm handling it.  Just want to make sure that the spec documents these situations, because they're currently left open to the reader.     Even though the spec says that all 3xx, 4xx, and 5xx responses (except 404) should be treated as retries, I'm questioning this more and more.  I don't have an answer in my head, yet, but I don't see anything that prevents a(/many) hub(s) from being utilized in a DoS against a server that has a known page which returns these values.     I think there needs to be a more refined definition of "reasonable number of times over the course of a longer time period (e.g., 6 hours)", and perhaps the minimum polling period.  e.g.  One retry per hour would severely limit the impact a single server could have against a targeted host.     I haven't yet, but likely will, also add subscription rate limiting against a single hostname/callback until at least one subscription request has been verified.  i.e. if I receive 1000 requests with a callback pointing to "target.example.com", I will either refuse or queue them until at least one has been accepted. -- Jay Rossiter | Software Engineer/System Administrator Pioneering RSS Advertising Solutions jrossi...@pheedo.com | Phone: 503.896.6187 | Fax: 503.235.2216 Website: www.pheedo.com | RSS: www.pheedo.info/index.xml