Slimming down the useless parts

This commit is contained in:
Nadja Reitzenstein 2022-03-11 23:59:18 +01:00
parent 63e74aacc0
commit 564a69ef35
2 changed files with 14 additions and 82 deletions

View File

@ -7,7 +7,6 @@ $Rust.parentModule("schema");
using CSharp = import "programming_language/csharp.capnp";
$CSharp.namespace("FabAccessAPI.Schema");
using L10NString = import "utils.capnp".L10NString;
using Session = import "connection.capnp".Session;
struct Response {
@ -18,80 +17,42 @@ struct Response {
badMechanism @1;
# The server does not support this mechanism in this context.
unwilling @2;
# Generic "I'm sorry dave, I can't do that" response. MAY be set for any reason, all reasons
# or no reason at all. This code will for example be used if a client is being rate limited.
# A server SHOULD set the `action` and `description` fields as appropiate.
# This code SHOULD only be sent if no other value is more fitting.
invalidCredentials @3;
invalidCredentials @2;
# The exchange was valid, but the provided credentials are invalid. This may mean that the
# authcid is not known to the server or that the password/certificate/key/ticket/etc is not
# correct.
unauthorized @4;
# The given authcid is not authorized to act as the requested authzid. This MAY also be
# returned for the cases `authzid == NULL` or `authzid == authcid`, for example because
# login is disabled for that authcid.
malformedAuthZid @5;
# The provided authzid is malformed in some way.
failed @6;
failed @3;
# A generic failed result. A server sending this result MUST set the `action` field to
# indicate whether this is a temporary or permanent failure and SHOULD set `description` to
# a human-readable error message.
}
enum Action {
# In case of a unsuccessful outcome, how should a client proceed?
unset @0;
# The server doesn't know either. A client SHOULD treat this either as as `retry` or as
# `wait`.
retry @1;
# A client SHOULD try again, depending on the `Error` after prompting the user for their
# credentials once more.
wait @2;
# The client SHOULD wait and retry after a grace period. A client MUST wait at least 500ms
# and SHOULD implement exponential backoff up to no less than 64s.
# This MAY mean that whatever failure happened was temporary or the server is applying
# rate-limiting to the connection.
permanent @3;
# The issue appears to the server as being permanent. Another try is very likely to return
# the exact same result. In most cases the user should notify the responsible system
# administrator. A client SHOULD NOT try to authenticate to the server again until the user
# manually indicates a retry.
}
union {
error :group {
code @0 :Error;
# Error code indicating the cause of the error
additionalData @1 :Data;
# Some mechanisms will send additional data after an error
}
# Some kind of error happened. This in the first entry in the union because it is the
# default set value meaning if a server fails to set any of the values, indicating some
# pretty severe server bugs, it is parsed as an "aborted" error.
result @0 :Error;
action @1 :Action;
description @2 :L10NString;
# A human-readable error description that is designed to be shown to the user in case of
# failure. Clients MAY NOT display this message if they understand the error e.g. for
# the error/action "invalidCredentials/retry".
}
challenge @3 :Data;
challenge @2 :Data;
# The data provided so far is not enough to authenticate the user. The data MAY be a
# NULL-ptr or a non-NULL list ptr of zero bytes which clients MUST pass to their SASL
# implementation as "no data" and "some data of zero length" respectively.
successful :group {
# The exchange was successful and a new session has been created for the authzid that
# was established by the SASL exchange.
session @4 :Session;
session @3 :Session;
# The session that was created. It grants access to all capabilities the connecting
# party has permissions for.
additionalData @5 :Data;
additionalData @4 :Data;
# SASL may send additional data with the successful result. This MAY be a NULL-ptr or a
# non-NULL list ptr of zero bytes which clients MUST pass to their SASL implementation
# as "no additional data" and "some additional data of zero length" respectively.

View File

@ -1,29 +0,0 @@
@0xed0c02f41fea6b5a;
interface L10NString {
# Any string type that is intended to be displayed to an user that is more than an identifier to
# be used as-is must be able to be localized into the users preferred language. This includes
# description, help messages, etc. but of course does not extend to usernames.
# TODO: Potentially make generic over the localized content (e.g. dates)? Can be done after the
# fact without braking protocol, so no big issue.
get @0 ( lang :Text ) -> ( lang :Text, content :Text );
# Retrieve the string in the given locale. The input parameter MUST be a RFC5646-formatted
# locale identifier (e.g: "en-US", "de-DE", "az-Arab-IR").
# A server MUST set the outputs `lang` to the exact tag that the content it sends was written in
# and `content` to the localized string.
# If a server can't find a localized version it SHOULD try to substitute it. Substitution SHOULD
# only search for close matches, e.g. returning "en-UK" for a string requested in "en-US" or
# returning "es-ES" for a requested "es-VE". Substitution MUST NOT return a localization that an
# user can not be expected to understand unless the server has a priori knowledge that the user
# can read and understand said language.
# If a server sends a substituted string it MUST set the output `lang` to the tag of the
# substitute it is sending.
# If a server can't find a suitable substitute or is not doing substitution it MUST set the
# output `content` to a NULL pointer and set the output `lang` to the input `lang` it was
# passed.
# If a server can't parse a given `lang` tag it MUST set the output `lang` to a NULL pointer.
available @1 () -> ( langs :List(Text) );
# Returns the list of locales this content is available in.
}