-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating previous subscriptions that have a hub.secret #47
Comments
I think the issue raised on #36 could be helpful here. |
^ I am wrong! |
The key is in
We should make it that when the subscribers gets a 2nd verification request, it ignores it completely. |
Doesn't this make subscription verification non-idempotent? |
I guess the right answer is "it depends". Basically the subscriber should response the same but ignore them. So from a protocol standpoint they're idempotent. |
The subscriber has no way to distinguish a (second or subsequent) verification-of-intent resulting from a request it made from a verification-of-intent made by some other party. So it has to acknowledge verification success consistently in all cases, it seems to me. ... unless Another interesting idea might be to allow an un/subscriber to supply |
Like I said:
;p I see no use in |
@aaronpk Are you satisfied wth the answers? Can you clarify anything we should discuss further? |
This kind of got off track from my original questions.
I've sent a PR with a sentence that clarifies the above: #92
We kind of lost the discussion thread here. It seems like the subscriber's verification endpoint should not just blindly echo the challenge for every request it gets, is that true? |
Yes of course. I think the subscriber should always check on their end whether they want to accept a verification. This may involve checking things against business logic, but also things like whether a subscription has already been confirmed, or whether it is expired...etc |
I guess this is already covered by "The subscriber must confirm that the hub.topic corresponds to a pending subscription or unsubscription that it wishes to carry out." so I don't see any further language that needs to be added. |
If a subscription is currently active for a subscriber that used a
hub.secret
when creating the initial subscription, is it okay if a new subscription request comes in without ahub.secret
? It looks like just the topic and callback are used to identify a previous subscription:I believe there is no risk in allowing a future request that doesn't have a secret, because:
In particular, I'm thinking of a case where an attacker tries to make a subscription request for a subscriber that previously used a secret. When the subscriber gets a subscription request, it must only acknowledge the verification if it specifically requested it, otherwise it's possible for someone to turn a signed subscription into an unsigned subscription.
There are two issues I would like to see some clarification on:
The text was updated successfully, but these errors were encountered: