Re: [stellation-res] Authentication problem

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: <stellation-res@xxxxxxxxxxxxxxx>
Sent: Tuesday, March 18, 2003 9:38 AM
Subject: Re: [stellation-res] Authentication problem


> Jonathan Gossage wrote:
>
> >There is a problem in
>
>org.eclipse.stellation.remote.engine.Engine.requestResourceAuthentication()
.
> >There are circumstances where it is possible that you will never receive
a
> >response from the server. I ran into this because the Id for the Firebird
> >database I was connecting to contains the full path to the database and I
> >typed the drive letter in lower case on the client side and upper case on
> >the server side. Since the server did not find the Id, it silently
discarded
> >the challenge request without responding.
> >
> That's actually the correct behaviour: the client is supposed to time
> out on it's authentication
> request, which generates an authentication error.
>
> We've got a deliberately odd communication layer,  which leads to some
> counter-intuitive
> behaviours until you get the sense of it.
>
> It's a publish-subscribe system. In pub-sub, you don't know who the
> intended recipient of
> a message is. You publish a message onto a communication bus, and anyone
> who is interested
> in that kind of message subscribes to the message type.
>
> So, in Stellation, servers subscribe to the "auth.request" message, to
> receive authentication requests. But the design is intended to permit a
> given message bus to include more than
> one server - so there can be multiple subscribers to authentication
> requests. The client
> *can't* know how many subscribers there are - that's a kind of
> distributed knowledge
> that a simple pub-sub doesn't permit.
>
> Therefore, having the server respond to say it can't find the resource
> accomplishes nothing, because you don't know if the response is coming
> from the right server.  That's why
> we use timeout. So I guess that the real bug is that the timeout in the
> auth code
> is failing to properly generate an auth failure when it doesn't recieve an
> auth.challenge.
>
>     -Mark

The timeout code in the client loops forever retrying the challenge so the
client never learns about the failure.

Regards

Jonathan