Hello Damian,
Please excuse the delay.
On 5/4/06, Damian Minkov <damencho gmail.com> wrote:
> 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.AuthorizationHand
ler
>
net.java.sip.communicator.service.protocol.AuthorizationRequ
est
>
net.java.sip.communicator.service.protocol.AuthorizationResp
onse
> 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
> 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
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
Cheers
Emil
------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
|