mirrors/arti.git/crates/arti-rpcserver/src/session.rs, branch arti-v1.1.5mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.52023-05-24T14:15:56Zrpc: Remove downgrade_owned for now2023-05-24T14:15:56ZNick Mathewsonnickm@torproject.org2023-05-24T13:24:45Zurn:sha1:936387efee359a38a22a920568090b204dfd07be
Rationale: Our weak-vs-strong design is a bit confused at the moment
due to concerns about deduplication and capability semantics. It's
not clear that a general "change strong to weak" method is
compatible with what we want to provide.
rpc: Implement functionality to remove objects from a session2023-05-24T14:15:56ZNick Mathewsonnickm@torproject.org2023-05-23T14:41:56Zurn:sha1:9713e8d3054aafe3f19afd55693bc3159712e595
I've made doing some design choices here:
* Reserving "rpc" as a prefix for post-authentication
functionality that is not arti-specific.
* Declaring these to be methods on the session rather than methods
on the objects themselves.
There's a problem with defining an API to drop a weak reference; see
comment in code.
rpc: Make the top-level returned object a "session".2023-05-24T14:15:56ZNick Mathewsonnickm@torproject.org2023-05-23T13:58:32Zurn:sha1:fef8342be3ad75e3eb7645d239a36f29529a019f
This will make it easier to change the semantics of what exactly we
return, whether it has to be/contain a client, whether you can use
it to look up all the live objects, &etc.
RPC: Rename session.rs to connection.rs2023-05-04T14:35:05ZNick Mathewsonnickm@torproject.org2023-04-28T17:42:46Zurn:sha1:b807e834a3c06ed9183a119795101628a543c1f3RPC: rename Session to Connection.2023-05-04T14:35:05ZNick Mathewsonnickm@torproject.org2023-04-28T17:40:23Zurn:sha1:7845f04908872bf153a4b12916df600822e39cb9
To me, "Session" suggests that we're authenticated, when we are
not necessarily authenticated. Also, we may eventually want to have
some kind of persistent session object; if we do, then we'll want
Connections to be separate.
RPC: Make authentication return a TorClient.2023-05-04T14:35:05ZNick Mathewsonnickm@torproject.org2023-04-28T03:25:29Zurn:sha1:94df123932adcd10adee4c91c790ae519d9d9802
(This is the correct capabilities-based behavior. For now it will only
work if the TorClient uses a PreferredRuntime, but with luck we will
find a solution for #837 soon.)
RPC: Add "register" methods to RequestContext.2023-05-04T14:35:05ZNick Mathewsonnickm@torproject.org2023-04-25T21:08:47Zurn:sha1:9be9ddb9027fef615613118451bc7e98fbc533b5RPC: Move the "listen" part of the RPC listener code to `arti`.2023-05-04T14:30:40ZNick Mathewsonnickm@torproject.org2023-04-20T17:49:31Zurn:sha1:879a4532126fca59baa3a8e1764b1a1363ddeee5
Now there's a module in `arti` that runs the loop for an RPC
listener. The part of the old `listener` module that made
the framed connections is now part of the `Session` object.
There is now yet another a temporary location for the pipe; we
should pick something better. At least now it's configurable.
rpc: Make an RpcMgr type to own the DispatchTable.2023-05-04T14:22:27ZNick Mathewsonnickm@torproject.org2023-04-19T11:59:17Zurn:sha1:25398b5a3b613ce0272b8f933179824759323ba2
In the future, this will probably hold more data as well, like a
TorClient and some configuration info.
The TorClient will present an issue; I've made comments about that.
Closes #820
RPC: Log all internal errors.2023-04-19T16:38:26ZNick Mathewsonnickm@torproject.org2023-04-19T16:35:49Zurn:sha1:7c1f45a514c0c6f5579be939151a3f75db62d731