From: Havoc Pennington Date: Sat, 1 Nov 2003 18:24:32 +0000 (+0000) Subject: 2003-11-01 Havoc Pennington X-Git-Tag: dbus-0.20~1 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=d8beff11cde324e45b6421a815c314d625bc9c5e;p=thirdparty%2Fdbus.git 2003-11-01 Havoc Pennington * doc/dbus-specification.xml: add state machine docs on the auth protocol; just a first draft, I'm sure it's wrong. --- diff --git a/ChangeLog b/ChangeLog index fd0000d56..5711a5116 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2003-11-01 Havoc Pennington + + * doc/dbus-specification.xml: add state machine docs on the auth + protocol; just a first draft, I'm sure it's wrong. + 2003-10-28 David Zeuthen * python/dbus_bindings.pyx.in: add get_dict to handle dictionaries diff --git a/doc/TODO b/doc/TODO index de77933a3..6c56f9b68 100644 --- a/doc/TODO +++ b/doc/TODO @@ -102,7 +102,9 @@ dbus_message_get_args() which takes a DBusError. Probably we need to either fully encapsulate and hide dbus/dbus.h, or encapsulate it slightly less e.g. no - GError. + GError. Or maybe it's as simple as "never return dbus_malloc() + memory" and just fully encapsulate the get_args() type of + stuff. - need to define bus behavior if you send a message to yourself; is it an error, or allowed? If allowed, diff --git a/doc/dbus-specification.xml b/doc/dbus-specification.xml index 42bd51380..5f62cfdd9 100644 --- a/doc/dbus-specification.xml +++ b/doc/dbus-specification.xml @@ -1048,8 +1048,163 @@ Authentication state diagrams - WRITEME + This section documents the auth protocol in terms of + a state machine for the client and the server. This is + probably the most robust way to implement the protocol. + + + Client states + + + <emphasis>Start</emphasis> + + + send AUTH with initial data -> WaitingForData + send AUTH with no initial data -> WaitingForData or NeedSendData (depends on mechanism) + + The Start state is stateful (it has a list of + available mechanisms and those it has already attempted). This list + is used to decide which AUTH command to send. When the list is + exhausted, the client should give up and close the connection. + + + + + <emphasis>WaitingForData</emphasis> + + + + receive OK -> NeedSendBegin + receive REJECTED -> Start + receive ERROR -> Start + receive DATA -> NeedSendData + receive anything else -> NeedSendError + + When going back to Start, the mechanism in + progress should be marked as failed and not retried (at least not + with the same parameters). When receiving REJECTED with a list of + mechanisms, the list should be recorded and used to select + a mechanism. + + + + + <emphasis>NeedSendData</emphasis> + + + send DATA -> WaitingForData + send CANCEL -> Start + + + + + + <emphasis>NeedSendError</emphasis> + + + + send ERROR -> return to previous state + + + + + + <emphasis>NeedSendBegin</emphasis> + + + + send BEGIN -> Authorized + + + + + + <emphasis>Authorized</emphasis> + + This is the end state, flow of messages begins. + + + + + + + Server states + + + <emphasis>WaitingForAuth</emphasis> + + + receive AUTH with initial response -> NeedSendData + receive AUTH without initial response -> NeedSendData or WaitingForData depending on mechanism + + + + + + <emphasis>NeedSendData</emphasis> + + + send DATA -> WaitingForData + send ERROR -> WaitingForData + send REJECTED -> WaitingForAuth + send OK -> WaitingForBegin + + + + + + <emphasis>WaitingForData</emphasis> + + + receive DATA -> NeedSendData + receive CANCEL -> NeedSendRejected + receive ERROR -> NeedSendRejected + receive anything else -> NeedSendError + + + + + + <emphasis>NeedSendError</emphasis> + + + + send ERROR -> return to previous state + + + + + + <emphasis>NeedSendRejected</emphasis> + + + + send REJECTED -> WaitingForAuth + + + + + + <emphasis>WaitingForBegin</emphasis> + + + + receive BEGIN -> Authorized + receive anything else -> NeedSendError + + + + + + <emphasis>Authorized</emphasis> + + This is the end state, flow of messages begins. + + + + + Authentication mechanisms