#7 OTRproxy behaves poorly in multi-user settings

[Len Sassaman]

[Under OS X 10.3.9, otrproxy 0.2.0...]

If user Alice is running a chat client configured to use the proxy
settings that correspond to the ports on which an instance of
otrproxy being run as user Bob is listening, unexpected behavior
occurs.

OSCAR traffic is proxied successfully. OTR traffic which generates
dialogue boxes will result in those dialogue boxes being displayed on
Bob's login session.

Multiple crash events have been observed in the course of
debugging this, leading us to suspect this is not a use case that has
been considered.

(If Bob is logged in, and running otrproxy, Alice cannot run her own
instance of otrproxy on the default ports, as they are already bound.)

Immediate work-around: require each user to run his otrproxy on a
seperate port.

Fix: otrproxy should have an "active" and "inactive" mode, where in
the "inactive" mode, it unbinds from the ports on which it is
listening. otrproxy should catch the "switch user" event, and put
itself into "inactive" mode in that event, freeing the proxy ports so
that another instance of otrproxy can be started by the other user.

For greater functionality in multi-user systems, the ability to have a
system-wide otrproxy with user-specific dialogue displays may be
worth investigating.

[Nobody/Anonymous]

Logged In: NO

hi