| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes #950.
|
| | |
|
| |
|
|
|
|
| |
This will later let us tell the session-creation function
how the authentication occurred, which will let it decide
what privileges to provide.
|
| | |
|
| |
|
|
|
| |
We'll want to move the responsibility for creating Sessions outside
the rpcmgr crate.
|
| |
|
|
|
|
|
| |
These identifiers are actually only "global" with respect to a given
`RpcMgr`, but they should not be forgeable or reusable across RpcMgr
objects. We're going to use them so that we have a kind of identifier
for `TorClient`s that we can expose to SOCKS.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
See the comments on `TypedAddr` for some explanations about
why this is so tricky. Thanks to @diziet for helping me figure
this out.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit big, but it's not that _complicated_.
The idea here is that we use serde's "untagged" enum facility
when parsing our `Request`s, such that if parsing as a `Request`
fails, we parse as an `InvalidRequest` and try to report
what the problem was exactly.
This lets us determine the ID of a request (if it had one),
so we can report that ID in our error message. We can also
recover from a much broader variety of errors.
We now also conform with the spec reporting errors about
completely wrong json, requests without IDs, and so on.
|
| | |
|
| |
|
|
|
| |
It requires tokio, it's unix-only, and makes some unfortunate
shortcuts. Probably good enough for initial testing.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Ordinarily you can cancel a future just by dropping it, but we'll
want the ability to cancel futures that we no longer own (because we
gave them to a `FuturesUnordered`).
|
| |
|
