[OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación
Saúl Ibarra
saghul at gmail.com
Wed Aug 22 10:03:07 CEST 2007
Bueno, finalmente lo he dejado como muestro a continuación. Trato
todos los tipos de mensajes en alguna ruta, y los que no interesan
pues error 405. Espero que esta sea la mejor manera...
## Mensajes con destino nuestro servidor (por ejemplo llamadas a
usuarios registrados aquí).
## Tenemos que tratar explicitamente el ACK
if (method=="ACK") {
xlog("L_INFO","$Cbx--- Procesando un ACK *not within a dialog*$Cxx\n");
route(1);
exit;
}
## CANCEL messages can be safely processed with a simple call to
t_relay() because SER will automatically match the CANCEL message to
the original INVITE message (stateful).
## Para los CANCEL, con la ruta por defecto vale.
else if (method=="CANCEL") {
route(1);
exit;
}
## Los REGISTER los tratamos a parte (en la ruta 2)
else if (method=="REGISTER") {
route(2);
exit;
}
## Los INVITEs a la ruta 3 (autenticacion,...)
else if (method=="INVITE") {
route(3);
exit;
}
## Los MESSAGE, OPTIONS y REFER tienen que ir autenticados
else if (method=="MESSAGE" || method=="REFER" || method=="OPTIONS") {
route(8);
exit;
}
## Resto de casos?
else {
sl_send_reply("405", "Method Not Allowed");
xlog("L_INFO","\n\n$Cbc[$rm] -- 405 - Method Not Allowed$Cxx\n");
exit;
}
El 21/08/07, Saúl Ibarra <saghul at gmail.com> escribió:
> Me respondo a mi mismo, con algunas conclusiones... espero me
> corrijáis si me equivoco :P
>
> El 21/08/07, Saúl Ibarra <saghul at gmail.com> escribió:
> > Hoola!
> >
> > En algún hilo se ha comentado el tema de qué mensajes deberían ir
> > autenticados o no, pero como no era el tema central, he decidido abrir
> > este otro hilo para comentar mi pregunta/cosa:
> >
> > Según he leido por aqui (creo que lo comentó Iñaki), los mensajes que
> > tienen que autenticarse con el proxy_authorize y tal son:
> >
> > -INVITE
> > -REGISTER
> > -MESSAGE
> > -SUBSCRIBE
> > -PUBLISH
> > -OPTIONS
> >
> > Vale, si esta es la lista, entonces yo ahora mismo tengo un
> > problemilla de seguridad, así que quería verificar una cosa:
> >
> > Los INVITE se suelen tratar en u route aparte, así como los REGISTER.
> > Aunque todavía no me he metido mucho con ello, PUBLISH y SUBSCRIBE
> > también irían aparte, porque están relacionados con la presencia.
> >
>
> Todo esto OK.
>
> > Entonces me quedan MESSAGE y OPTIONS. Actualmente he estado probando
> > los mensajes sin autenticación y por supuesto iban OK. Ahora he
> > añadido este bloque para manejarlos:
> >
> > # -----------------------------------------------------------------
> > # MESSAGE handler
> > # -----------------------------------------------------------------
> >
> > route[8]
> > {
> > xlog("L_INFO","$Cbx-- Mandando un MESSAGE --$Cxx\n");
> >
> > ## Es necesario autenticarse
> > if (!proxy_authorize("","subscriber")) {
> > xlog("L_INFO","$CbxSe necesita autenticacion para el MESSAGE$Cxx\n");
> > proxy_challenge("","0");
> > exit;
> > }
> >
> > ## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
> > else if (!check_from()) {
> > xlog("L_INFO","$Crx*** check_from() = NO!! ***$Cxx\n");
> > sl_send_reply("403", "Use From=ID");
> > exit;
> > };
> > xlog("L_INFO","$Cbx*** MESSAGE correcto ***$Cxx\n");
> > consume_credentials();
> >
> > # Puede que venga a nosotros pero tengamos definido un alias a fuera.
> > lookup("aliases") nos da la nueva URI que puede sea !=myself.
> > lookup("aliases");
> > if (!is_uri_host_local()) {
> > xlog("L_INFO","$CrxNot my URI after the alias lookup$Cxx\n");
> > ## A las salientes
> > route(4);
> > exit;
> > };
> >
> > ## Miramos si existe el destino en nuestra tabla "location".
> > if (!lookup("location")) {
> > xlog("L_INFO","$Crx404 User Not Found$Cxx\n");
> > sl_send_reply("404", "Not Found");
> > exit;
> > };
> >
> > ## Si hemos llegado hasta aquí enrutamos el mensaje al destino por la
> > ruta por defecto.
> > route(1);
> > exit;
> > }
> >
> > La pregunta es: podría utilizar este mismo bloque para los OPTIONS?
> >
>
> No se como generar un OPTIONS, xD pero por lo que he leido ese bloque
> deberia servirme para los MESSAGE, OPTIONS y REFER, ya que pide el
> auth y tal.
>
> > Entonces, llegados a este punto (sorry por la chapa) nos quedan por
> > tratar CANCEL, BYE, INFO, REFER, UPDATE, y PRACK?
> >
> > Bien, entonces, asumiendo que tenemos esto en nuestro route principal:
> >
> > if (!is_uri_host_local()) {
> > if (is_from_local()) {
> > route(4);
> > }
> > else {
> > sl_send_reply("403", "Forbidden");
> > };
> > exit;
> > }
> >
> > Si un cuanlquiera nos manda algo pasaremos de ello. Entonces, para los
> > CANCEL y los BYE podemos hacer t_relay tranquilamente.
> >
>
> No, los BYE solo deberian ocurrir dentro del dialogo, manejados por loose_route.
>
> > Los INFO solo ocurririan en loose_route no?Al igual que los UPDATE?
> >
>
> Los INFO también los manejamos con loose_route.
>
> > Ya solo nos quedan REFER, UPDATE y ese PRACK que no se yo... :P
> >
> > Segun leo en el RFC3515, "REFER request MAY be placed outside the
> > scope of a dialog" entonces, deberia tratarlo fuera del loose_route?
> > Iria autenticado?
> >
>
> Si, deberia.
>
> El tema es que en todos los ejemplos que he visto, en la seccion en la
> que se van mandando a distintos routes dependiendo del metodo, como
> asi por ejemplo:
>
> ## Los REGISTER los tratamos a parte (en la ruta 2)
> else if (method=="REGISTER") {
> route(2);
> exit;
> }
>
> ## Los INVITEs a la ruta 3 (autenticacion,...)
> else if (method=="INVITE") {
> route(3);
> exit;
> }
>
> Luego al final, si no ha entrado por ninguno de los if se comprueba el
> alias, el location, y se hace relay. Esa parte no me gusta, y quiero
> tratar cada mensaje explicitamente, por lo tanto, que pasaria si no
> dejo los UPDATE y PRACK? Parecen "opcionales"...
>
> > PD: Sorry por la "pesadilla mail", si aun os quedan fuerzas tras haber
> > llegado hasta aqui: que hacemos con el PRACK? (aunque no lo he visto
> > nunca...)
> >
> > --
> > Saúl -- "Some people say why, other just say, why not."
> > ----------------------------------------------------------------
> > http://www.saghul.net/
> >
>
>
> --
> Saúl -- "Some people say why, other just say, why not."
> ----------------------------------------------------------------
> http://www.saghul.net/
>
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
More information about the Users-es
mailing list