[OpenSER-Users-ES] Re: [Users-es] Mensajes que requieren autenticación

[Saúl Ibarra]

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/