These are chat archives for fanout/pushpin

19th
Apr 2018
Adam McElwee
@acmcelwee
Apr 19 2018 15:49
Is there any concept of forced renegotiation for the client<->pushpin connections? I'm trying to find a way to limit the lease time, based on the initial response from the backend.
We'd like to force periodic renegotiation of the clients to handle access-control revocation in our systems.
and it needs to be server-side enforced, vs renegotiation at the client level and just trusting that no one compromises that
Adam McElwee
@acmcelwee
Apr 19 2018 15:54
I haven't seen the existence of anything like this, but another option would be if there's a sort of meta api that lets us find the current client/channel/channel-age triple for each pushpin server and then we could send a channel close to pushpin for anything that's past our allowed age.
So, happy to do the connection management ourselves, if the right meta information is available.
Justin Karneges
@jkarneges
Apr 19 2018 17:12
@acmcelwee what transport are you using?
Justin Karneges
@jkarneges
Apr 19 2018 17:19
there are a couple of ways I can think of doing this. one is to have pushpin contact your server periodically as a way to renegotiate, which varies by transport. the other is to maybe bucket your expirations by time period and subscribe each client to a bucket (e.g. everyone connecting from T=0 to T=10 gets subscribed to expire-0 and then at T=20 you publish a close to expire-0)
Adam McElwee
@acmcelwee
Apr 19 2018 17:22
We're in the "survey the real-time tools landscape" phase, so nothing setup yet.
For transport, do you mean client <-> pushpin, or pushpin <-> backend?
Justin Karneges
@jkarneges
Apr 19 2018 17:23
client<->pushpin. for example, if you use http streaming, you can configure pushpin to periodically make a request to the backend on behalf of the client and you can reevaluate the subscriptions
Adam McElwee
@acmcelwee
Apr 19 2018 17:24
ws, most likely
Justin Karneges
@jkarneges
Apr 19 2018 17:25
for websockets, basically same thing. pushpin can send events to the backend over http, and can be configured to periodically check in even if there are no client events
Adam McElwee
@acmcelwee
Apr 19 2018 17:25
great - I haven't seen any docs on that. Got any pointers on where to look for that?
Justin Karneges
@jkarneges
Apr 19 2018 17:27
it's a bit hidden away at the moment. for websockets, the detail is here: https://pushpin.org/docs/protocols/websocket-over-http/#notes
backend responds with Keep-Alive-Interval header
Adam McElwee
@acmcelwee
Apr 19 2018 17:28
excellent
I think this is enough for us to spin up a quick prototype
Justin Karneges
@jkarneges
Apr 19 2018 17:30
you'll probably want to combine this with metadata (discussed on same page) to make it easier to validate the client
Adam McElwee
@acmcelwee
Apr 19 2018 17:31
yeah, we'd basically need to pass along the client's jwt token
but, yeah, I see that in the docs
Thanks a lot, this is super helpful!
Justin Karneges
@jkarneges
Apr 19 2018 17:32
if the client passes the token as a header, you'll get it in every request from pushpin. if the client passes the token as a message, then you can use meta to maybe apply it as metadata to the session (or maybe just the parts you need, like the user id and expiration time)
Adam McElwee
@acmcelwee
Apr 19 2018 17:33
it'll come as a header