>
>However, in thinking about it, I don't think there is any way to avoid
>your solution of pid/secret key. The postmaster, on receiving the
>secret key, can send a signal to the backend, and the query will be
>cancelled. Nothing will be sent along the backend/client channel. All
>other interfaces that want cancel handling will have to add some code
>for this too.
>
Assuming that every user has a password which is known by both the client
and the server, it seem to me like using a one-way function based on the
clientuser password as the secret key (refered to above) is appropiate.
This avoids the need for introducing "yet another shared secret into the
system".
A one-way function is expected to make it computationaly infeasible to
deduce the password given the secretkey. One-way functions (SHA1, MD5) are
also quite fast. (If I'm not mistaken these functions are allowed to be
exported
from the US. )
By including a cancel request id (together with the user password) with the
information being hashed (by the one-way function) it is also possible to
detect (and avoid) denial of service attacks
(which are based on replaying the cancel request secret keys).
This does however imply that a certain amount of extra booking is needed.
With regards from Maurice.