Hi Jeff, On Oct 26, 8:07 pm, Jeff Lindsay <[email protected]> wrote: > So I guess there are two ways OAuth can be used: > > 1) For the hub to auth with the subscriber > 2) For the hub to auth with the publisher > > And it sounds like you're talking about #1, right?
Yes. I'm talking mostly about the #1 case. However, I see that the publish part doesn't necessarily need to be authenticated. Or at least OAuth may not be the solution for that. Since the hub does not really publish anything it only receives the notification and does the content distribution to the subscribers. For example, someone publishes something to a private feed and notifies the hub. The publishing is done outside PubSubHubbub. The hub then fetches the feed (if it has subscribers) and the feed naturally has to be fetched N times if there are N subscriptions since each has to be authenticated separately. Hmm... does this make any sense? ;) > Perhaps I'm ignorant of OAuth details, but most implementations I've seen > require a UI approval step. Would that be the case here? Yes. My idea was that the hub does a GET with hub.mode="authorize" to the subscriber's callback URL and there delivers a URL which points to the service provider's OAuth authorize URL where the request token needs to he authorized. The subscriber then needs to deliver this URL to the end-user somehow. I know that PubSubHubbub is meant mostly for server-to-server use, but if we want it to be able to handle private feeds end-user has to be involved somehow anyways. End user then opens the URL via a browser and grants the authorization to the application in question and hub gets the access token. I know this is not an easy problem to solve. That's why I think a proof-of-concept implementation would be useful. I'm kinda working on that still, but would like also to hear opinions from others before banging my head against the wall for nothing. :) - Teemu
