German Castro Donoso wrote: > Hola, > > Me gustaria saber si existe o alguien conoce alguna politica estandar para > elegir un numero de puerto alternativo. > > En particular tengo que reemplazar el puerto 4444 (servicio RMI en servicor > de aplicación j2ee) por otro libre, y me gustaria saber si hay alguna regla > de "buenas costubres" mejor que elegir cualquier puerto desocupado. > > Gracias > Germán > > aunque me imagino que ya revisaste, en http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers hay un listado de puertos oficiales y no oficiales para servicios.
aunque no sale ahi el port 4444. saludos From [EMAIL PROTECTED] Wed Sep 26 17:30:26 2007 From: [EMAIL PROTECTED] (Rodrigo Fuentealba) Date: Wed Sep 26 17:42:55 2007 Subject: Evitar sql injection y xss In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> El 26/09/07, Ricardo Mun~oz A. <[EMAIL PROTECTED]> escribió: > Cristian Rodriguez wrote: > > Ricardo Mun~oz A. escribió: > > > > > >> shuata... entonces no tienes idea que CakePHP lo puedo ejecutar sin > >> problemas en PHP5? cual es la idea de de tanto FUD con respecto a Cake? > >> > > > > No es FUD, si esta programado para una version del lenguaje obsoleta, > > llena de limitaciones y errores el resultado va a ser malo auqnue > > funcione el versiones posterioires. > > > > y sigues con tu FUD; estas diciendo que todas las aplicaciones que > funcionan con PHP4 estan llenas de limitaciones y errores solo debido a > la version del lenguaje. pero, lo que tambien estas diciendo (sin darte > cuenta?) es que si PHP5 me acepta el mismo codigo que PHP4 No todo funciona igual. Hay un registro de cambios en www.php.net para poder migrar de php 4 a php 5.2 > automaticamente PHP5 pasa a ser igual de limitado y lleno de errores > como PHP4. Ejejejeje, pongámoslo fácil: Compré un equipo de radio marca PHP modelo 4.3 que sólo me soporta escuchar bandas AM y escuchar vinilos. Luego compré un equipo de radio marca PHP modelo 5.2 que soporta bandas AM, FM, TV y escuchar CD-ROM's, pero como puedo escuchar AM, ¿es igual de limitado? No sé en qué parte del Universo vives tú, pero acá en el planeta Tierra, el segundo equipo de radio no es tan limitado como el primero. > (si PHP4 me permite escribir codigo malo, entonces tambien me > lo va permitir PHP5). Si tú usas PHP 5 como si fuera PHP 4, y no lees los cambios, los hints de seguridad y todas esas cosas; es lo mismo que usar Python 3.0 si sigues usándolo como si fuera Python 1.2, o Visual Basic .NET 2005 con los objetos DCOM de Visual Basic 6: no es problema del lenguaje, sino de "tu" forma de utilizarlo. Considera seriamente volver a estudiar PHP. > te das cuenta de eso? Entiende: PHP 5 es un lenguaje completamente nuevo, con backwards compatibility (a medias), hacia PHP 4, pero cuya forma recomendada de usar es completamente distinta, cuya manera de declarar las clases (públicas, protegidas y privadas, algo que tengo entendido que PHP 4 no soporta completamente bien, pero no tengo ningún PHP 4 para comprobarlo) es distinta, cuya manera de organizar el código para terminar con el spaghetti es mucho mejor. > ademas, PHP4 sera soportado hasta el an~o 2012 en RHEL4, CentOS4, etc. > (ver [1]) por lo que tu FUD de que "PHP4 no esta soportado" tampoco es > cierto. El soporte que RHEL 4, CentOS 4 u otra distribución le da a las aplicaciones cuyo release ha pasado consiste en hacer "backporting" de muchos parches. Si PHP 5 reescribió completamente su esquema de clases y objetos, ¿me puedes decir qué clase de marañas tendrán que hacer cuando se pille un error en esta parte de PHP 4, y cuánto se demorarán en parcharlo? El soporte que te ofrece RHEL refiere a incluirlo en la distribución, mantenerlo funcionando y que no se rompa ante otras bibliotecas, pero ellos "no" son totalmente expertos en el funcionamiento de PHP y aún si picaran código, el duplicado de esfuerzos conllevaría, en este caso, a inconsistencias. Slackware ya retiró de sus filas a PHP 4 y no lo recomienda para nada, ya pasaron sus años de fama; Slackware 11 lo mantendrá sólo hasta que sea viable, y eso no será por mucho. Cristian que te cuente sobre SuSE. Eso ocurre cuando el cambio es drástico en una distribución, cosa que en el caso de MySQL, no importa, porque reimplementan sobre lo mismo y no hay mucha diferencia entre el código que comparten 5.0.41 y 4.1.11 (pero sí la hay en el código que se agregó). > ahora, antes de que R.Fuentealba diga que estoy defendiendo > PHP4, aclaro altiro que es obvio que PHP5 es mucho mejor, pero hay que > ser suficientemente inteligente para darse cuenta que en la realidad > existen (muchos) miles de hosts con PHP4 que no van a migrar a PHP5 en > el corto/mediano plazo. ¿Por ejemplo? Esos hosts son aquellos a los que les interesa ganar plata y DEBEN ser tildados de irresponsables; podrían adquirir demandas (aunque en la práctica, nadie lo hace y todos se resisten por un tema de "comodidad" y "no entregar un buen servicio"). Todos los informáticos sabemos que un sistema que está en línea, expuesto a personas cuyos orígenes no conocemos más que por su dirección IP (y si es que...) > por lo mismo CakePHP es una buena opcion (para cierto tipo de > aplicaciones web) ya que permite pasar a produccion aplicaciones web en > un rango mas amplio de hosts. la version 2.0 de Cake sera > PHP5/6-only[2], sin duda esa version sera re-escrita pero sin afectar > mayormente su API, que es en el fondo lo unico que importa en cualquier > framework. ¿Entonces habrá lugares en que debes sanitizar por ti mismo? > en todo caso, la proxima vez que te toque recomendar Symfony vs. CakePHP > podrias decir que Cake no soporta PKs compuestas, en cambio Symfony > si... IMHO ese podria ser (para algunos) el unico "punto en contra" de > Cake. la tontera de PHP4 (malo) vs. PHP5 (bueno) lo veo totalmente > irrelevante. Claro, por omisión el usuario debería pensar que una versión nueva trae más y mejores features, y debe informarse acerca de ellas antes de elegir una versión anterior, y no elegir una versión anterior "porque la nueva es muy nueva" (muy nuevo serán 2 días; 15 días; pero no 3 años). -- Rodrigo Fuentealba