Overview

No post anterior, eu expliquei a idéia por trás da publicação de category instances. Nesse parte vamos ver como podemos controlar para quais usuários a informação é publicada.

Essa feature funciona para qualquer tipo de category instance. Está relacionada com publicar informações diferentes para diferentes grupos de usuários.

O Container

O container é uma especialização de uma category instance. Isso significa que adicionar ou remover containers é feito através do processo de publicação de category instances.

O container tem a idéia de armazenar informações de publicação para um conjunto de usuários. O conjunto de usuários é definido por: usuários do mesmo domínio, mesma empresa, “federated enterprise”, publico ou todos, ou ainda construindo o grupo usuário a usuário.

Geralmente a organização dos containers vem do mais permissivo com Id’s mais baixos e os mais restritivos com Id’s mais altos.

Uma boa organização de containers seria:

• ContainerID 0: Everyone
• ContainerID 100: Federated enterprise
• ContainerID 200: Company
• ContainerID 32000: Blocked

O Microsoft Office Communicator tem uma organização similar. A lista completa está aqui: Microsoft Office Communicator Presence Categories

Se você está escrevendo o seu próprio cliente baseado na UCC API, você precisa criar a organização inicial dos containers, publicando as category instances como “static” (para que o servidor as persista). O Microsoft Office Communicateor faz a configuração inicial no seu primeiro login.

Como os direitos no container são verificados

Para publicar as informações de categorias usando listas de controle de acesso (ACL ou access control lists), o servidor OCS segue a seguinte lógica:

• O servidor começa a publicação dos containers mais restritivos para os mais permissivos. Exemplo: Se um usuário está no container “Blocked” (32000), este usuário irá receber as informações publicadas no container 32000.
• Se existe informação publicada no container, essa informação é enviada.
• Se não existe informação publicada no container mais restritivo, a informação do container mais permissivo é publicada.

Vou mostrar alguns exemplos para ilustrar essa idéia. Todos os exemplos seguem a configuração de container mostrada anteriormente.

Example 1:

• Usuário Paul não tem o usuário Mary como membro de nenhum container.
• Usuário Paul tem o usuário John como membro do seu container 32000 (blocked users)
• Usuário Paul publica o estado “Available” nos containers 2 e 3.
• Usuário Paul publica o estado “Offline” no conatiner 32000.
• Usuário Mary recebe o estado “Available” do usuário Paul. Isso acontece porque Mary cai na regra “Everyone” na configuração de containers.
• Usuário John recebe o estado “Offline” do Paul.

Example 2:

• Usuário Paul não tem Mary como membro de nenhum container.
• Usuário Paul tem John como membro do container 32000 (blocked users)
• Usuário Paul publica o estado “Available” nos containers 2 and 3.
• Usuário Mary recebe o estado “Available” do Paul. Isto acontece porque Mary cai na regra “Everyone” da configuração de containers.
• Usuário John recebe o estado “Available” do Paul. Isto acontece porque nenhum estado foi publicado no container 32000. Quando isso acontece a informação mais permissiva é publicada.

Esta regra aplica-se para todo e qualquer tipo de category instance. Informações de contato, por exemplo, segue a mesma regra. Você pode publicar mais informações para usuários mais confiáveis e menos informações para usuários que você não confia.

Especificamente para a feature de bloqueio de usuários, esse é o jeito certo de fazer. Nâo existe uma feature especifica para bloquear usuários, exceto esta de “remover permissão de ver o estado “disponível” para o usuário.

Conclusão

Para evitar problemas as listas de controle de acesso (ACL’s) da UCC API devem ser corretamente configuradas, especificamente os containers e membros dos containers. Sempre que ocorre uma publicação, é importante publicar a informação mais restritiva e mais permissiva em cada um dos seus containers (Ex.: Estado disponível e offline).

Infelizmente a documentação do MSDN não é muito clara sobre este assunto, especificamente a idéia de ter que publicar a informação mais restritiva. Em outras palavras, o estado “Offline” no exemplo.