[sip-comm-dev] Authorization implementation


#1

Hello Damian,

Please excuse the delay.

I'm looking now for implementing the authorization in the icq protocol implementation. The interfaces and classes that exist : net.java.sip.communicator.service.protocol.AuthorizationHandler net.java.sip.communicator.service.protocol.AuthorizationRequest net.java.sip.communicator.service.protocol.AuthorizationResponse Actions that must be taken in the code

Yes. The only thing is the fact that AuthorisationRequest and
AuthorisationResponse are empty at the moment. I'll try and fill them in
as soon as possible so that you could use them.

1. Register some factories in the joscar that will handle incoming packets and inform the implementation for events . AuthCmdFactory - will receive messages for authorization requests, authorization responses and message informing that someone else has added us to the contact list. AuthFutureCmdFactory - incoming future authorization permission. This eventually only must pop up an info dialog in the gui about the event.

Yes.

2. When error adding buddy received - fire some event so gui window can be opened to ask user whether to request auth and to give reason.

Yes, though not exactly an event. You'd need to call the
createAuthorizationRequest() method of the AuthorizationHandler and it
will be up to the UI to decide what to do. It might even not pop up a dialog
at all if it has previously been configured as to how to create such
requests
(i.e. with a default reason).

3. request auth to user with reason. Send him future auth also.

this would actually be the result of the createAuthorizationRequest()
method.

4. fire event auth request received

That woul be:

AuthorizationHandler.processAuthorizationRequest()

5. fire event auth denied received

AuthorizationHandler.processAuthrorizationResponse()

6. fire event auth accepted received

Once again

AuthorizationHandler.processAuthrorizationResponse()

7. fire event user has added you to his contact list

We don't have this one now. I'll think about it. You could simply ignore
it for the time being.

Now for the implementation.

Oh ... I wrote all of the above without seeing that you've actually
written it urself. :). Well doesn't matter :slight_smile:

1. when setting AuthorizationHandler in the OperationSetPersistentPresenceIcqImpl the factories must be registered.

You mean that at this point they must already be registered or that this
is when you should register them? I personally believe that the tow are
decorelated. You could register the factories as soon as you can - i.e.
upon connection and the authorization handler is to be set at some other
moment.

Currently, there is a setAuthorizationHandler() method which is not the
way to go. The authorization handler will be set upon creation of the
provider so that there could be only one. I'll have to finish that soon
as well.

2. AuthorizationHandler.createAuthorizationRequest must be called. 3.
with the result from AuthorizationHandler.createAuthorizationRequest
we can send the request. If returned null then this indicates that user has canceled the operation and nothing to be done.

Yes!

4. AuthorizationHandler.processAuthorisationRequest with the result return from this we can send the accept/deny response.

Exactly.

5. call AuthorizationHandler.processAuthorizationResponse

Yes

6. call AuthorizationHandler.processAuthorizationResponse

Yes

7. may be left for now as not implemented , or we must change the service interfaces and add this somewhere else.

Ha :slight_smile: Exactly. I really had to read the whole message before replying.
This is exactly what I was saying :).

The objects AuthorizationRequest and AuthorizationResponse must be changed. AuthorizationRequest add String reason; and boolean allowFutureAuthorization; AuthorizationResponse add String reason; and boolean accepted;

Yes and yes.

Am I right? Any suggestions ?

Yes, absolutely. No other suggestion :slight_smile:

Cheers
Emil

···

On 5/4/06, Damian Minkov <damencho@gmail.com> wrote:


#2

The implementation is committed now I'm working on the tests
I'm wondering now on the scenario of the tests here is my idea which I've started to implement - look at the attachment
Any ideas ? What else can be done in the tests ?

auth-tests.pdf (22.6 KB)


#3

Hello Damian,

Some modifications to ur scenarios.

Emil

Damian Minkov wrote:

auth-tests.pdf (30.1 KB)

···

The implementation is committed now I'm working on the tests
I'm wondering now on the scenario of the tests here is my idea which I've started to implement - look at the attachment
Any ideas ? What else can be done in the tests ?