From d8beff11cde324e45b6421a815c314d625bc9c5e Mon Sep 17 00:00:00 2001 From: Havoc Pennington Date: Sat, 1 Nov 2003 18:24:32 +0000 Subject: 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. --- ChangeLog | 5 ++ doc/TODO | 4 +- doc/dbus-specification.xml | 157 ++++++++++++++++++++++++++++++++++++++++++++- 3 files changed, 164 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index fd0000d5..5711a511 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 de77933a..6c56f9b6 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 42bd5138..5f62cfdd 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 -- cgit