[AsteriskBrasil] Funcao Cadeado

[Andre Ruiz]

Foi eu que mandei.

O authenticate vai resolver o problema, mas vai autenticar sempre, se
você colocá-lo antes das rotas de saída. O que eu propus permite que
você controle por ramal. Até daria pra misturar os dois (eu usei DISA,
poderia ter usado o authenticate diferenciando o ramal por contexto).

E tem outra difereça muito importante: usando o authenticate, você
apenas decide se passa ou não passa a ligação, baseado numa senha. Se
passar, as credenciais serão as do ramal que está discando. Com o
DISA, você troca totalmente o ramal e contexto para os selecionados no
arquivo de senhas, de forma que as credenciais usadas na ligação
passam a ser de quem usou a senha. Meu cliente queria exatamente isso:
ter 100 ramais, e 2000 senhas, onde cada um que tinha uma senha
poderia pegar um ramal livre e discar, usando a própria senha, o
sistema bilhetaria no nome dele (e no ramal virtual dele, que não tem
ninguém logado normalmente mas tem um número válido para efeito de
bilhetagem).

Pense no que é melhor pra você. Segue abaixo o texto, novamente:

==========================8<--------------------------------------------

Eu implementei um sistema de cadeado pra um cliente há algumas
semanas. Não ficou "uma brastemp" mas foi o que veio à cabeça na hora.
Certamente ainda vou tentar desenvolver um melhor para colocar no
lugar depois.

Nesse caso específico, nós estávamos usando uma instalação baseada em
AMP/AAH, e o que fiz foi o seguinte:

1) Criei um contexto novo, chamado cadeado, e coloquei nele uma
extensão que chama o DISA. A extensão pode chamar por exemplo *00.
2) Dupliquei o contexto "from-internal" com o nome "from-internal-semcadeado".
3) Retirei o contexto all-outbound e incluí o contexto "cadeado" no
contexto "from-internal". Opcionalmente você pode também incluir o
contexto "cadeado" no "from-internal-semcadeado".

Agora você tem um contexto default que não disca pra fora, mas pode
discar *00 pra cair no disa. E os ramais que você quer livrar do
cadeado, basta trocar o contexto default deles para o -semcadeado que
eles voltam ao normal. Fiz assim porque a quantidade de ramais que não
teriam cadeado era pequena. Se for o contrário, inverta os nomes, vai
dar menos trabalho.

O DISA vai ler uma base de dados de senha, onde cada usuário vai ter
que digitar sua senha para poder ganhar um tom de linha e daí fazer a
ligação. O contexto onde o DISA disca é o all-outbound-routes.

Agora, se alguém que está num ramal cujo contexto não tem o
all-outbound-routes, se ele tentar ligar pra fora, vai falhar. Ele vai
precisar discar *00, daí virá um novo tom de linha pra discar a
senha... Depois de discar a senha (se ela for válida), virá um novo
tom de linha onde ele disca pra fora. Se for discar pra ramais
internos, basta discar direto, pois está no contexto default dele.

Não creio que o DISA seja um problema de segurança nesse caso, pois
você vai estar rodando o disa no contexto all-outbound-routes, que ele
já teria acesso de qualquer forma, você só colocou uma senha no
caminho. (É normal ver o DISA como furo de segurança quando não for
bem usado).

Desculpe não poder dar mais detalhes, creio que meu empregador não
permitiria que eu colasse aqui o que foi feito lá exatamente. Mas você
entendeu a idéia :-)

Observações:

1) O DISA não pergunta usuário, apenas a senha. É como se o
número-senha fosse um login e senha ao mesmo tempo. Isso pode ser
ruim, pois na hora de mudar a senha de alguém você precisa verificar
se não repetiu outra senha.

2) É possível que alguém disque senhas sequenciais até achar alguma
válida, já que não tem login. Use senhas de muitos dígitos e bem
espaçadas entre si, e veja nos logs se pega alguém tentando fazer
isso.

3) A maneira com que o DISA opera faz com que ele mude o caller ID de
saída da ligação para aquele associado ao ramal de quem está discando,
mesmo que essa pessoa tenha ido usar o ramal de outro usuário. Isso
faz com que nos CDRs apareça quem ligou e nunca de onde ele ligou (não
dá pra ter idéia se foi do telefone dele mesmo ou não). Isso não é tão
ruim, mas é importante saber.

4) Não use essa solução como definitiva, tente bolar alguma coisa
melhor. Como eu disse, foi só um quebra-galho até implementar alguma
coisa melhor. E, quando você bolar alguma melhor, manda ela pra mim,
heheheh :-)

Abraços,
andre


On 9/29/06, Leonardo Kamache (Gmail) <lkamache em gmail.com> wrote:
> Dê uma olhada na aplicação authenticate. Deve ser isso que está querendo.
>
>
> Abraços;
>
> LK
>
>
>
>
> On 9/28/06, bruno em connectech.com.br <bruno em connectech.com.br> wrote:
> > Senhores,
> >
> > A algum tempo atras foi enviado uma mensagem para a lista com a funcao
> cadeado no extensions.conf e
> > outra funcao que nao me lembro. Se alguem ou o autor enviar novamente
> aquela mensagem seria muito
> > interessante. Estive olhando o historico e nao consegui encontrar.
> >
> > Grato,
> >
> > Bruno
> >
> > Bruno Mayworm - Consultor de T.I.
> > Connectech Networks
> > (24)92268387
> > ----------------------------------------
> > Estação VoIP 2006
> > 5 e 6 Dezembro
> > Curitiba PR
> > http://www.estacaovoip.com.br
> >
> > _______________________________________________
> > LIsta de discussões AsteriskBrasil.org
> > AsteriskBrasil em listas.asteriskbrasil.org
> >
> http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
> >
> > _______________________________________________
> > Acesse o  wiki AsteriskBrasil.org:
> > http://www.asteriskbrasil.org
> >
>
>
> ----------------------------------------
> Estação VoIP 2006
> 5 e 6 Dezembro
> Curitiba PR
> http://www.estacaovoip.com.br
>
> _______________________________________________
> LIsta de discussões AsteriskBrasil.org
> AsteriskBrasil em listas.asteriskbrasil.org
> http://listas.asteriskbrasil.org/mailman/listinfo/asteriskbrasil
>
> _______________________________________________
> Acesse o  wiki AsteriskBrasil.org:
> http://www.asteriskbrasil.org
>
>


-- 
Andre Ruiz  <andre.ruiz em gmail.com>
Curitiba, PR, Brasil