| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\
| |
| |
| |
| | |
rpclib: Clean up after performing cookie auth
See merge request tpo/core/arti!2716
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
rpc: Rename new_stream_handle to new_oneshot_client.
Closes #1664
See merge request tpo/core/arti!2715
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
This method doesn't actually create a new stream; it creates a
single-use client object that can be used with SOCKS to launch
a new stream, and capture an RPC object for that stream.
Closes #1664.
|
| |/
|
|
| |
Closes #1500.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We don't want to call this "unix path" anywhere, since it
corresponds to _any_ case where the ability to negotiate a
successful connection means that the client is authorized.
We also don't want to call it "none": The authentication
is inherent to the connection, not nonexistent.
|
| |
|
|
|
|
|
|
|
|
| |
Previously participants in the cookie protocol only bound the peer
nonce in their MACs. With this change, they bind both nonces.
This change is _probably_ not necessary for security, but it can't
hurt. It follows a general principle that Adam Langley told me a
long time ago: you won't regret binding more, but you might regret
binding less.
|
| |
|
|
|
| |
Since this is a secret value, it's probably best not to copy it
all over the place.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Now that we have a solid idea of how connections happen,
it's clear we won't need to enable this negotiation mechanism.
|
| |
|
|
| |
Closes #1753
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes the separate function for asking whether to
bypass the dispatch code. Instead, it gives the "invoke with
bypass" function an error to return when no dispatch is warranted,
and moves the whole responsibility for method dispatch or
non-dispatch back into tor-rpcbase.
I had to add an ObjectId argument to `invoke_rpc_method` to make
this work, but that's probably a good thing.
Additionally, this commit tweaks the derive-deftly macro to prevent
you from asking for dispatch bypass on special methods, where it
isn't implemented (and doesn't really make sense).
|
| | |
|
| |
|
|
|
|
|
| |
Now, instead of telling the session or the connection to drop the
object ID, we tell the object ID to go away.
Closes #1663.
|
| | |
|
| |
|
|
|
| |
If and when we implement this, it will likely be different;
arti#868 has some thoughts on the implications.
|
| |
|
|
|
| |
These will have different implementations soon; this is a more
logical place for them.
|
| |\
| |
| |
| |
| | |
Fix typo in arti-rpcserver auth.rs comment
See merge request tpo/core/arti!2558
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our spec says that when the RPC client has said "I require you to have
feature X" and we don't have it, we need to include the feature(s)
we don't have in an `rpc:unsupported_features` field of our error.
Also, add an integration test for this behavior.
Closes #1662
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These are not regular ErrorKinds, since they can never occur in an
error that's meant to be returned from a Rust API like
`arti-client`. Instead, they only exist for errors returned from
RpcError.
(I can't find the place where we discussed this previously, but the
rationale is that if an ErrorKind never makes sense in response to
something that the user does from Rust, we should never have that be
an ErrorKind. The fact that the removed kinds do not actually
appear outside the RPC system suggests that this is reasonable.)
|
| |/
|
|
|
|
|
|
|
| |
I'm about to remove HasKind from InvokeError, which would otherwise
break this code.
These errors are all in fact internal errors, since in this context
they can only stem from incorrectly formed calls to
`invoke_special_method`.
|
| |\
| |
| |
| |
| |
| |
| | |
Use clippy to prevent non-mq use of mpsc::channel
Closes #1659
See merge request tpo/core/arti!2536
|
| | |
| |
| |
| |
| | |
We need to decide whether RPC will participate in memquota.
Perhaps it should. But that's for the future.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
| |
We have defined a forward-compatibility mechanism for the RPC
system, where a request may list one or more required "features",
and if any feature is absent, the request will fail.
Since no "features" are currently implemented,
this code does the bare minimum to implement this mechanism,
by rejecting every request with a nonempty "require" field.
|
| |
|
|
|
| |
The `update` field in request.meta is optional, so we should allow
it to default to `false` when it is absent.
|
| |
|
|
|
|
|
| |
The spec no longer says that `params` is optional, so we can remove
the TODO about making it optional.
Closes #1665.
|
| |
|
|
| |
Based on review from @opara.
|
| |
|
|
|
|
| |
Previous documentation was more-or-less meant for the Arti developer
only. This new documentation is intended for actual users of RPC
functionality. It's meant to be extracted with `maint/rpc-doc-tool`.
|
| |
|
|
|
|
|
|
|
|
| |
Calling it "singleton" might have suggested that it was using the
[singleton pattern](https://en.wikipedia.org/wiki/Singleton_pattern),
which it isn't.
(Renaming done with rust-analyzer and double-checked with `git grep`.)
Closes #1585.
|
| | |
|
| |
|
|
|
|
| |
I've used an `async{ expr }.await` pattern, to make sure that
_every_ error returned by the `loop{select!{}}` construct is
actually transformed.
|
| |
|
|
| |
(This will make the next commit easier to read.)
|
| | |
|
| |
|
|
| |
Per suggestion from @diziet.
|
| |
|
|
|
|
| |
Instead of classifying errors and complicating our behavior _early_
in our loop, instead we just decide whether an error indicates an
EOF immediately before we return it.
|
| |
|
|
|
|
| |
Make it more clear than the previous match statement
that once we get an Err() from request_stream.next(),
we aren't going to continue the loop.
|