[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