- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 298
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
Major spec changes #288
Major spec changes #288
Conversation
About mercure.payload, can it be used as a sub-topic? For example: htts://mercure.rocks/subscriptions/vendor/dogs Is it correct? |
@dmouse Sorry I don't understand exactly what you mean. The payload is a random data structure you add to the subscriber's JWT. Then, this data structure is attached to the subscriber, and included in subscription events related for this subscriber. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise, very nice 👌
The hub **MAY** discard some messages for operational reasons. The subscriber **MUST NOT** assume | ||
that no update will be lost, and **MUST** re-fetch the original topic to ensure this (for instance, | ||
after a long disconnection time). | ||
The reserved value `-1` can be used to hint the hub to send all updates it has for the subscribed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is confusing to me. I'd have expected -1
to actually be used as a relative value to only return the last event. I'd go for a much more explicit all
constant.
I believe that the rejection of the mechanism of targets was the wrong decision. Suppose we have a single page application that contains two thousand entries. Even entries owned by userA, and odd entries owned by userB. An entry have properties "id", "status" and "owner". (It's important that an application is SPA: user get an authorization token for Mercure only once, when start an application.) @dunglas could you describe an example of solution for my example case, when we need to publish status updates in SPA for users with a lot of entries and we can't subscribe it for concrete entries by their enumeration? |
@a-menshchikov you can use URI templates for this use case:
Then you can set What do you think? |
@dunglas it seems less clear than it was with targets mechanism, especially if we have tens of different entry classes in our application. Previously, we had to generate JWT for user with one target for himself ( As result we have more complicated code of JWT generation and we cannot segregate JWT generator and core application because it should know about entry classes. |
Also this approach requires me to solve an issue how to pass the username to client (that need for a subscription url entry/forUserA/{id}/status). With targets mechanism client doesn't need to know anything about private subscription principle. It basically get JWT from backend that contains information about allowed targets, and then retrieve from hub granted messages. It's much more simpler than need to make JWT with all private topics and pass the username to client. |
This can be solved using URI templates.
No because it's just an alternate IRI. Client can still refer to the canonical IRI which doesn't need to contain a reference to the user name. It solves all problems you describe. WDYT? Regarding the previous example, the client can still subscribe to |
@dunglas this solution works, thank you! |
@dunglas So if I want to publish the same update for the several users I need to use multiple topics, right?
For example, we have the chatroom in our chat. This chatroom contains 1000 users at the moment. Will it be 1000 topics in POST request with just different users? |
For a chat room there is an easier way:
This way, you every messages can have a single topic, and all authorized users can receive them. |
@dunglas I thought about this way, but if we add So I consider the way I mentioned in the previous post but I want to make sure that I understand everything correctly because I used targets earlier and I want to update Mercure. |
This a major spec change intended to fix most remaining limitations. I hope that it can be the last breaking change.
Authorization
This is the main change.
The authorization mechanism has been simplified. It's currently the major pain point for users. The concept of
target
is difficult to understand. In this proposal, targets are gone. The new mechanism is much simpler:private
by setting theprivate
property while publishing it.mercure.subscribe
claim of this JWT. It's also possible to use a raw string (it can be a URL or just a random identifier) instead of a URI template.Subscription events
/.well-known/mercure/subscriptions/{subscriptionID}/{topic}
(it washtts://mercure.rocks/subscriptions/{topic}/{subscriptionID}
). Using well-known URL for this looks cleaner to me.mercure.payload
), and this user-defined payload is included in the subscription events. It is convenient to store a user ID, an IP, groups and so on.Event Store and State Reconciliation
The Hub can now be used as an event store (to implement event sourcing for instance) thanks to a simple trick: the event ID
-1
is now reserved, and using-1
as value for theLast-Event-ID
header or query parameter now hints the hub to send the full history for the subscribed topic(s).I'm not sure about
-1
, it could be0
too, orall
, or any other reserved value. Don't hesitate to share your thoughts about this.Identifiers
It's now possible and recommended to use IRIs everywhere: as topics and as event ids. For convenience, it's also possible to use random string (not IRIs) everywhere.
Encryption
The key set (JWKS) is now exposed through an external URL.
Next steps