Skip to content
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

[Access] Add client id for subscriptions #6637

Open
Tracked by #6163
Guitarheroua opened this issue Nov 12, 2024 · 1 comment
Open
Tracked by #6163

[Access] Add client id for subscriptions #6637

Guitarheroua opened this issue Nov 12, 2024 · 1 comment

Comments

@Guitarheroua
Copy link
Contributor

Guitarheroua commented Nov 12, 2024

Should be discussed with FCL team due to comment: #6630 (comment)

@jribbink
Copy link
Contributor

jribbink commented Nov 12, 2024

Thanks for making this issue @Guitarheroua.

@illia-malachyn 's comment from the other thread:

The ID in SubscribeMessageResponse is generated on the server side to ensure that each subscription has a unique identifier. This approach prevents clients from spoofing or forging IDs, enhancing security by reducing the potential for unauthorized access or manipulation. By associating the Topic with this unique ID in the response, clients can reliably match a SubscribeMessageRequest to its corresponding SubscribeMessageResponse.

Topic is indeed redundant and might not be included in a response. We're still discussing it

My concern is that associating subscribe requests to responses on the basis of Topic alone can be ambiguous if a client sends multiple consequetive SubscribeMessageRequest messages to the server with the same Topic.

Presumably this is a potential scenario when a user wants to subscribe to the same topic multiple times, but with different parameters.

It seems to me that either:

  1. Some sort of identifier must be sent from the client to associate SubscribeMessageRequest and SubscribeMessageResponse messages.

    Sorry for initially stating that this should correspond to the same ID as SubscribeMessageResponse was maybe a mistake on my part - this can be a totally different identifier.

  2. OR The server must guarantee in-order delivery of SubscribeMessageResponse messages. In this case, I can just add pending subscriptions to a queue on the client-side & associate them with incoming responses in-order.

Maybe 2. is already a guarantee, and in this case this would not be an issue to worry about. But I just wanted to bring it up in the case that it isn't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants