Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - big_ed

#41
Cita de: #!drvy en 14 Agosto 2019, 10:04 AM
Hola,

En general lo tienes bien aunque supongo que esos datos los estas guardando en una base de datos. En tal caso, te recomiendo usar sentencias preparadas si es que no las estas utilizando ya.
https://www.php.net/manual/es/mysqli.quickstart.prepared-statements.php - MySQLi
https://www.php.net/manual/es/pdo.prepared-statements.php - PDO

De todos modos, te dejo el como lo haría yo por si pillas alguna idea o algo.

Código (php) [Seleccionar]
<?php

function validate($input$type$required false)
{
    if (
$required && empty($input)) {
        throw new \
Exception('No ha rellenado unos de los campos obligatorios');
    }

    
// Nos aseguramos de que el input no va a ser mayor de 1024 caracteres.
    
if (mb_strlen($input'utf-8') > 1024) {
        throw new \
Exception('Uno de los campos contiene demasiados caracteres.');
    }

    switch (
$type) {
        case 
'user':
            
$valid preg_match('/^[[:alpha:]\s]{2,50}$/iu'$input);
            
$error 'El campo Nombre permite un máximo de 50 caracteres de solo letras mayusculas o minusculas';
            break;

        case 
'email':
            
$valid filter_var($inputFILTER_VALIDATE_EMAIL);
            
$error 'El campo Correo no es válido.';
            break;

        case 
'phone':
            
$valid preg_match('/^[0-9]{1,11}$/'$input);
            
$error 'El campo Teléfono permite un máximo de 11 caracteres numericos';
            break;

        case 
'text':
            
$valid = (mb_strlen($input) <= 900);
            
$error 'El campo Texto no puede contener más de 900 caracteres';
            break;
    }

    if (!
$valid) {
        throw new \
Exception($error);
    }

    return 
htmlspecialchars(trim($input), ENT_QUOTES);
}

if (isset(
$_POST['submit'])) {
    try {
        
$user validate($_POST['text'], 'user'true);
        
$email validate($_POST['mail'], 'email'true);
        
$phone validate($_POST['telf'], 'phone');
        
$post validate($_POST['post'], 'text');

        
// Guardar datos en base de datos con sentencias preparadas
        
echo 'Válido';

    } catch (\
Exception $error) {
        echo 
$error->getMessage();
    }
}




Las principales diferencias son:

- Meto toda la validación en una función.

- Uso FILTER_VALIDATE_EMAIL para validar correo en vez de regex. En tu regex por ejemplo, el correo juan@undominiomuylargo.productions no validaria porque además de sobrepasar los 30 caracteres que le pones de límite en general, sobrepasa los 9 caracteres que le pones de limite al TLD (aquí tienes la lista de TLDS actuales), según estándar se permite hasta 63 caracteres de longitud para un TLD..

- Validó la longitud min/max de los campos en el propio regex ahorrando un IF.

- Garantizo que los caracteres son tratados como UTF-8 sobre todo en el campo de Nombre donde si te fijas usó un Character class de regex para decirle que coja todo carácter alpha (letras) y trato la expresión como unicode. Por defecto, si no tratas los strings como multibyte, los caracteres fuera del ASCII genérico son tratados como dos bytes. Por ejemplo strlen devuelve 2 para la letra Ñ (mb_strlen devuelve 1). Así permites que haya nombres como Iñaki o Jóse.


Si te soy sincero, yo no utilizariá htmlspecialchars para "sanitizar" el input. Dado que las sentencias preparadas ya se encargan de que no haya una inyección SQL por culpa de caracteres raros, guardariá los datos sin "sanitizar" (aparte de los requerimientos como por ejemplo solo números para el teléfono) y la hora de imprimir (mostrar) dicho campo, utilizariá htmlentities.



Lo peor que puedes hacer es una lista negra de caracteres. Es mejor hacer una lista blanca y permitir solo los caracteres que tu quieras a hacer una negra y que tengas que estar cada 2x3 metiendo caracteres nuevos porque resulta que ó no es lo mismo que ò pero el sistema los trata igual. Es un poco como el intento de censurar palabras malsonantes en este foro, la palabra ***** esta censurada (te pone las * cuando lo publicas) pero la palabra m.ierda o mierda o mierda no  :laugh:


No se, ya nadie da soporte para IE9.. es un poco absurdo hoy en dia. Nosotros por ejemplo solo damos soporte para las 2 últimas versiones de cada navegador (IE10, IE11). Es una versión que tiene ya 8 años y no es tan vital como IE8. Es decir, si tienes IE 9, no hay ninguna razón para que no tengas IE 10 o IE 11. IE 8 en cambio es un poco más vital en ese sentido porque fue la última versión de IE con soporte para XP. Pero vamos, estamos hablando de navegadores que llevan AÑOS sin actualizarse y con estándares obsoletos cuanto menos.

Saludos

. Tú cuando haces un formulario de contacto guardas los datos en una base???
Porque yo los voy a enviar a un correo directamente, con la funcion MAIL.

. Entonces con mi expresion regular sería solo cuestion de aumentarles los caracteres permitidos al correo..
Y tienes razon, creo que puedo meter mas condiciones en el regexp, como por ejemplo la de limite de longitud (y todas las que pueda) y asi  ahorrame codigo

. SI no voy a enviar los datos a una base , y por ende no voy a poder usar las sentencias preparadas ¿entonces esta bien que siga con HTMLSPECIALCHARS?...Aunque francamente no entiendo por que debo repetir la limpieza de datos, ya que mis expresiones regulares de por si ya evitan que se ingresen caracteres extraños ¿acaso las expresiones regulares no son 100% seguras? Digo, para que usar htmlspecialchars y addslashes , si mi expresion ya restringe todo eso...siento que es redundante

. Bueno pero al menos dime los caracteres que debo evitar, no para hacer una lista negra, sino para yo saberlo

. Es verdad que ya casi nadie da soporte a IE9,10 desde que aparecio Edge, aunque igual debe haber gente que aun lo tenga , y bueno no me quiero arriesgar, tampoco es que IE9 Y 10 sean muy antiguos.....en cambio i8 ese si ya fue...yo tengo ese trauma de que por ejemplo alguna vez algun viejito me pida ver mi pagina, ingrese y se vea toda desconfigurada

. En conclusion y para finalizar, para hacer un formulario seguro ¿debo cuidar que no ingresen sentencias en la url y en los campos de inputs?
Yo quiero que me digas en terminos simples cual debe ser mi objetivo para hacer el formulario seguro, que lo digas directamente, para yo asi ingeniarmelas ...porque si solo sigo unos pasos que me dicen pero si saber para que sirven exactamente entonces nunca voy a ser bueno en esto de la seguridad, porque solo estaria repitiendo lo que otros hacen sin saber su verdadera finalidad...
Quiero que me digas por ejemplo "mira, solo debes evitar que en los inputs pongan este signo '>>>'".. ..entonces yo ya sabria cual es mi meta y simplemente invertiria tiempo en mi ingenio

Gracias
#42
Cita de: string Manolo en 14 Agosto 2019, 03:31 AM
No tenía ni idea de que no eran compatibles O.o

Disculpa, no los vi, me cuesta leer códigos sin antes darles formato con alguna herramienta.

Yo menos, no se ni defenderme adecuadamente de ataques que sí se realizar... Por algo no publico mis servers y solo acceden usuarios registrados a través de proxies y tengo 50.000 copias de seguridad en todos sitios, le tengo pendrives puestos para archivos importantes y los voy alternando por si hasta me jodiesen el pendrive que está puesto.

Si es para un sitio serio tuyo o si tienes contrato con alguien ten cuidado que si algún usuario del sitio es estafado debido a que se filtran sus credenciales en tu sitio, si te denuncia lo vas a tener que pagar.  :-(




entiendo , no es tu rama
yo en cambio si tengo la necesidad de saber la compatibilidad de una tecnologia en todos los navegadores y sus versiones... cuando hago una web la pruebo en al menos los 5 navegadores mas importantes, en pc de escritorio, tablets, moviles, laptops, etc

si, el editor de codigo de muchos foros solo es blanco y negro...yo queria agregarle color al codigo para que se entendiera mejor pero no me lo permitio

que es eso de las credenciales?
yo por si acaso especifico que mi nivel alto es en diseño desde cero y programacion de animaciones...dejo claro que de seguridad informatica y SEO hago lo basico, para que una web funcione bien y sea etica su elaboracion...pero si quieren algo mas robusto y que se posicione en el primer lugar de google entonces que me paguen mas para contratar a un experto en esa rama o que ellos lo incorporen y que meta mano en mi codigo
No se puede saber de todo, quien mucho abarca poco aprieta , o algo asi era  ;D
Mejor especializarse en algo puntual
#43
Cita de: string Manolo en 14 Agosto 2019, 02:33 AM
Usa el input type adecuado solo estás usando text a pesar de soliciar un número y un email.Usar el tipo de input adecuado aseguro que el usuario no se equivoque al introducir los datos o le de sin querer a enviar y se te envien cosas inútiles al server para evitar que trabaje para nada. También evitas que el usuario envie datos erroneos sin darse cuenta.

exp1 y exp2 no las usas, supongo que porque ahí harás la tercera limpieza.

A parte de eso no veo nada más.





No sé como están implementadas las funciones, yo personalmente le hecharía un ojo a la implementación desde la perspectiva de un atacante para ver si hay alguna manera de saltarse la limpieza. Depende que hagas con lo que recibes. Si vas a publicar en el propio sitio, por ejemplo usando un document.write(Texto) si el filtro no es perfecto se pueden hacer cosas tipo:
Ejemplo de filtro inutil solamente buscando < > para evitar inserción de scripts.
Texto = FiltroAntiScripts(Texto);

//Contenido de texto:
var x = 60;
var y = 62;
x = asciiToChar(x);
y = asciiToChar(y);
var texto ="";
texto += x;
texto += "script";
texto += y;
texto += "alert(\"Soy un codigo malicioso xD\")";
texto += x;
texto += "/script"
texto += y;
//Fin contenido de texto.

//Tu código:
document.write(Texto);

Se pueden hacer muchas mierdas así.
Me imagino que la implementación está más que testeada, pero si por ejemplo tienes un decoder en tu código, podrían conseguir llamarlo pasándole como parámetro un script codificado que pase los filtros, pudiendo ejecutar el script desde una url de tu propio sitio. Tras lo cual enviando una url que a simple vista parece segura tipo https://www.elhacker.net/decode="agjw3ben72bfiwb5wk75fjw71637173jlspeb"/post.html

Ya me encontré fallos similares en muchos sitios. Hasta injectando rutas en el nombre de usuario para subir shells a carpetas con permisos o modificar algún archivo para tirar el server cambiándole el contenido a:
I'm an evil atacker, you should be scared. Buuuu.




Hints:
-Validate username serverside.
-Delete the last account created.
-Stop use the same credentials to share your accounts.


Jajaja
No estoy usando input de tipo mail o telf porque no son compatibles con Internet explorer 9.
Yo ignoro a internet explor 8 para abajo, pero del 9 para arriba siempre debe ser compatible.
tampoco uso placeholder ni required

Exp1 y exp2 si las uso, fijate bien , estan en el preg_match

Entonces solo me limitare a hacer la seguridad basica porque no soy un hacker experto, y si alguien quiere una super seguridad, pues que pague mas para subcontratar y llamar a un experto que refuerce, porque lo que es yo, no es mi rama
#44
Cita de: #!drvy en 13 Agosto 2019, 21:49 PM
Es un poco overkill pero si, puedes usarlo. Lo único, dado que regex tiende a ser algo lento y para evitar males mayores, limitaría los caracteres (un substr o parecido) para evitar así que me pasen cadenas de 20MB a filtar xD

Saludos
Justo iba a preguntar lo de arriba..Me parece que se podrian usar expresiones regulares literales. Voy a hacer un codigo y te lo muestro luego, para que me digas si es seguro o no.




Cita de: #!drvy en 13 Agosto 2019, 21:39 PM
Omitirlo. No se trata de ocultarlo, no tiene ningún sentido ocultarlo, se trata de no darle vías de input al que intente hacer el mal xD

PD: El codigo que he puesto estaba mal y lo he retirado, al parecer valida caracteres como <>"  lo cual lo hace inútil en estos casos. Quizás lo suyo seria utilizar FILTER_SANITIZE_STRING en ves de FILTER_SANITIZE_URL.

Saludos

Cita de: string Manolo en 13 Agosto 2019, 22:18 PM
No lo había pensado xDDD.

Ya programé otra vez el formulario, pero esta vez solo con PHP..díganme si está bien....Sólo falta lo del ACTION...pero ahorita lo hago y se los muestro también:


<form method="POST" autocomplete="off">
<input type="text" name="text" maxlength />
<input type="text" name="mail" maxlength />
<input type="text" name="telf" maxlength />
<textarea name="post" ></textarea>
<input type="submit" value="Enviar Correo" name="SUBMIT" />
</form>


<?php


if ( isset( $_POST['SUBMIT'] ) ) {

//PRIMERA LIMPIEZA
//PRIMERA LIMPIEZA
function _clean $p ) {
$cle trim$p );
$cle stripcslashes$p );
$cle htmlspecialchars$p );
return 
$cle;
}

$text _clean$_POST['text'] );
$mail _clean$_POST['mail'] );
$telf _clean$_POST['telf'] );
$post _clean$_POST['post'] );
$exp1 "/^[a-z\s]+$/i";
$exp2 "/^[a-z0-9._-]+@[a-z0-9.-]+\.[a-z]{2,9}$/";

if ( empty( 
$text ) || empty( $mail ) || empty( $telf ) || empty( $post ) ) {
echo 
"<script>alert( 'Rellena todos los campos!' )</script>";
} else {
    
//SEGUNDA LIMPIEZA
    //SEGUNDA LIMPIEZA
    
if ( strlen$text ) > 50 ) {
        echo 
"El campo Nombre permite un máximo de 50 caracteres";
    } elseif ( 
strlen$mail ) > 30 ) {
        echo 
"El campo Correo permite un máximo de 30 caracteres";
    } elseif ( 
strlen$telf ) > 11 ) {
        echo 
"El campo Teléfono permite un máximo de 11 caracteres";
    } elseif ( 
strlen$post ) > 900 ) {
        echo 
"El campo Mensaje permite un máximo de 900 caracteres";
    } elseif ( !
preg_match$exp1$text ) ) {
        echo 
"En el campo de Nombre ingresa solo letras, mayúsculas o minúsculas<br>";
    } elseif ( !
preg_match$exp2$mail ) ) {
        echo 
"Ingresa un correo válido!<br>";
    } else if ( !
is_numeric$telf ) ) {
        echo 
"Ingresa un número válido. Sólo números";
    } else {
        
//AQUI ENVIO LOS DATOS LIMPIOS AL SERVER
    
}
}
    
}


?>


:rolleyes:




Cita de: #!drvy en 13 Agosto 2019, 21:39 PM
Omitirlo. No se trata de ocultarlo, no tiene ningún sentido ocultarlo, se trata de no darle vías de input al que intente hacer el mal xD

PD: El codigo que he puesto estaba mal y lo he retirado, al parecer valida caracteres como <>"  lo cual lo hace inútil en estos casos. Quizás lo suyo seria utilizar FILTER_SANITIZE_STRING en ves de FILTER_SANITIZE_URL.

Saludos

El SANITIZE STRING me permite el simbolo ">" pero no el "<"
El HTMLSPECIALCHARS permite ambos..o sea que no sirve..
Pero ¿cuáles son exactamente los caracteres que debo evitar?
POrque yo podría impedirlos con expresiones regulares, pero quisiera saber cuáles son.
Si te fijas en el nuevo formulario que te he mandado ahi uso expresiones que solo permite texto ... Eso mismo podría intentar hacer pero en el ACTION.
El problema es que yo no sé nada de hackeo es por eso que no sé que cosa evitar. Si supiera sería más fácil.




Mod: No hacer doble/triple post.
#45
Cita de: string Manolo en 13 Agosto 2019, 21:52 PM
Lo ideal es validar tanto en el cliente como en el servidor. Por mucho que valides en el cliente, puede usar una herramienta tipo burpsuite, webscarab o cualquier otra herramienta con proxy del estilo para obtener las cabeceras, inyectar el código antes de enviarlas y hacer forward al servidor. Asique la validación por parte del cliente sirve más bien de poco en muchos casos. Valida siempre en el servidor. Si no te gusta PHP usa node.js

Pd: Acabo de fijarme en el código que pusiste. No tiene sentido. javascript se ejecuta en el navegador en el ordenador del usuario que visita la página. PHP se ejecuta en el servidor que tendrás tú en tu casa o en un hosting. No puedes ni ejecutar PHP en el navegador, ni ejecutar javascript en el servidor. (Con node.js sí, pero entonces no usas PHP para nada.)

Si quieres pasar los datos del form desde el navegador(javascript) al servidor PHP, necesitas usar cualquiera de las distintas formas de comunicarse con el servidor con html5 o javascript. Véase sockets, xmlhttp, etc.



Eres la tercera persona que me dice lo mismo, que de toda formas necesito validar con php, entonces ya no voy a validar con java script, se me hace un sinsentido validar con ambos , solo es una perdida de tiempo, porque al final la que importa es la validacion del lado del server ... mejor no me hago bolas y solo uso php
#46
Cita de: #!drvy en 13 Agosto 2019, 21:29 PM
Sinceramente, esos tutoriales o están escritos por inútiles o están obsoletos. Hoy en dia nadie te recomendaria semejante cosa.

La idea es que no necesites saber el nombre del archivo .php ni la query ni nada. Que se rellene sólo en base al baseurl que tiene PHP. Viene siendo una comodidad.


Antes de HTML5, el action era obligatorio según el estándar W3C, por lo tanto no lo podías dejar vacío ni omitir. A partir de HTML5, ya no es obligatorio por lo tanto lo puedes omitir (aunque no puedes dejarlo vació).


Pero de ser necesario, lo más adecuado es un sistema de templates donde ya se implementan ese tipo de funciones o en su defecto, filtrar el input para validar la URL:

Código (php) [Seleccionar]
$action = filter_input(INPUT_SERVER, 'PHP_SELF', FILTER_SANITIZE_URL);

Lo dicho, a partir de HTML5, puedes omitir el action.

Saludos

Pero que seria mejor entonces ¿omitir el ACTION como yo he dicho, O usarlo con ese codigo que tú me has puesto de sanitizar la URL?

Aunque si dices que la idea es ocultar el destino del action, si no lo pongo, en el codigo fuente apareceria vacio, y el hacker se daria cuenta que los datos van a la misma pagina, no?? ¿o me equivoco? Por otra parte, con el ECHO ¿se veria algo en el codigo fuente o en el inspector? Se supone que no
#47
Hola.

En muchos tutoriales de PHP enseñan que, cuando vas a recibir datos de usuarios (via formulario) en la misma pagina en donde te encuentras, lo mejor es hacer lo siguiente:

<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
</form>


Entiendo que si no rodeo a la superglobal $_SERVER('PHP_SELF') con HTMLSPECIALCHARS alguien podria poner codigo java script en la url y conseguir cosas...Pero lo que no entiendo es ¿por que es necesaria esa super global? Es decir, no seria mejor hacer simplemente esto?:

<form method="post" action="miweb.php">
</form>

AL hacer esto ya no funciona el codigo java script escrito en la URL.

O esto:
<form method="post">
</form>
#48
Hola  ::).

Estoy haciendo un formulario cuyos datos van a ser enviados con PHP pero "limpiados / filtrados" con Java Script. Al inicio queria hacerlo todo con PHP (se complica menos el no mezclar dos lenguajes distintos), es decir también la limpieza de datos, pero luego me di cuenta que más rápido sería primero limpiar / filtrar los datos con Java S. para luego enviarlos con PHP... Pero hacer esta mezcla me ha generado una duda y un conflicto:

1. Si ya estoy limpiando los datos con java script entonces no necesito hacerlo nuevamente con PHP, cierto?? Por lo tanto, funciones de PHP como trim(), stripslashes() y htmlspecialchars(), ya no deberian ser necesarias, correcto??? Abajo voy a poner mi codigo y veran como he limpiado los datos con js. Ademas como he limitado los caracteres extraños haciendo uso de las expresiones regulares.

2. ¿Cómo hago para meter codigo PHP en Java Script sin ocasionar conflicto? Esto es dificil de explicar asi que lo mejor sera que vean mi codigo para que entiendan lo que quiero decir...En el ultimo "else" explico esta parte:


//CODIGO HTML... MI FORMULARIO
//CODIGO HTML... MI FORMULARIO

<form method="POST">
<input type="text" name="text" maxlength />
<input type="text" name="mail" maxlength />
<input type="text" name="telf" maxlength />
<textarea name="post" ></textarea>
<input type="submit" value="Enviar Correo" maxlength />
</form>



//CODIGO JAVA SCRIPT... LA LIMPIEZA DE DATOS
//CODIGO JAVA SCRIPT... LA LIMPIEZA DE DATOS

<script>
document.forms[0].onsubmit = function () {

//recojo los valores de los campos
var text = document.forms[0]['text'].value;
var mail = document.forms[0]['mail'].value;
var telf = document.forms[0]['telf'].value;
var post = document.forms[0]['post'].value;
//creo expresiones regulares, la primera que solo permite texto, y la segunda valida un correo legitimo
var exp1 = /^[a-z\s]+$/i;
var exp2 = /^[a-z0-9._-]+@[a-z0-9.-]+\.[a-z]{2,9}$/;

if ( text=="" || mail=="" || telf=="" || post=="" ) {
   alert( "Rellena todos los campos!" );
   return false
} else {
   if ( text.length > 50 ) {
       alert( "El campo Nombre permite un máximo de 50 caracteres!" );
       return false
   } else if ( !exp1.test( text ) ) {
       alert( "Los nombres solo deben contener letras (mayúsculas o minúsculas) y espacios!" );
       return false
   } else if ( mail.length > 30 ) {
       alert( "El campo Correo permite un máximo de 30 caracteres!" );
       return false
   } else if ( !exp2.test( mail ) ) {
       alert( "Ingresa un correo válido!" );
       return false
   } else if ( telf.length > 11 ) {
       alert( "El campo Teléfono permite un máximo de 11 caracteres!" );
       return false
   } else if ( isNaN(telf) ) {
       alert( "Ingresa un número válido! Sólo hasta 11 digitos." );
       return false
   } else {
       //AQUI DEBERIA IR EL CODIGO PHP DE ENVIO DE DATOS
       Pero todo deja de funcionar cuando aqui agrego codigo php:
             
       <?php
       
echo $_POST["text"] . '<br>';
       echo 
$_POST["mail"] . '<br>';
       echo 
$_POST["telf"] . '<br>';
       echo 
$_POST["post"] . '<br>';
       
?>

   }
}

}
</script>
#49
Node no  veo que incite a las malas practicas (bueno hasta donde llegué en el curso). Es simplemente una sintaxis aparte de la normal de js (que no interfiere con la otra, no la deforma, solo es un complemento). Ni tan distinta tampoco porque se basa en objetos con sus metodos, propiedades y callbacks (ajax tampoco lo veo mal). Pero en cambio React , Angular, he visto como pervierten la forma de hacer html. Lo mismo Sass con el CSS. Y Boostrap como ensucia las etiquetas. He leido muchos manuales y siempre he seguido las buenas practicas y en ellas recomiendan tener el codigo lo mas limpio posible, el html hasta lo recomiendan con la menor cantidad de atributos (si todo se puede controlar desde el css).
Repito que no me opongo a que se creen extensiones que amplien las capacidades de un lenguaje, pero siempre que no deformen el codigo oficial ni acostumbren a las malas practicas (ademas siempre y cuando sean REALMENTE NECESARIAS...no cuando lo hagan por payasadas...lo que haces por ejemplo con REACT lo puedes hacer perfectamente con codigo puro, pero claro las agencias estan como apuraditas, quieren todo rapido, dinero, dinero, dinero, rapido y facil, por eso exigen estas tecnologias que aceleran la produccion, y de esta forma se convierten en un "estandar" no oficial, porque si no aprender te quedas sin trabajo ).. tampoco estoy a favor de instalar derivados y derivados y derivados de un lenguaje. POr ejemplo Jquery que de por si ya es un frameworl facil de aprender , hay gente encima de que ya es facilito le instala otro plugin y otro plugin y otro plugin...pues dime si eso no es mediocridad o flojera..¿no pueden hacer un slider ellos solos con jquery, que de por si ya te facilita bastante, que necesitan estar descargando plugin para que les haga todo el movimiento del scroll o slider? Lo mismo para worpress..han convertido las webs en una coleccion de blogs, con plugins como elementor con el que hasta un bebe puede hacer una web. Y las webs hechas con esta tecnoologia no son de buena calidad y tienen un monton de falencias que sus ""desarrolladores"" nunca dicen al cliente..pero ese es otro tema.
Lo del codigo maquina si me parece necesario compilarlo porque es demasiado dificil, eso es para robots...aparte yo estoy orientando a los lenguajes de programacion para la web.SI fuera programador de escritorio o de sistemas operativos tal vez me plantearia aprender eso o ensamblador, no lo se.Pero como te digo, si es una extension que va a hacer un cambio para bien, que es realmente necesaria, que no es payasada ni moda, y que no pervierte el codigo, entonces yo no lo critico....por ejemplo esos gestores de SVG me parecen correctos, porque yo he estudiado el manual de SVG y es imposible que alguien pueda dibujar lo que se hace a mano alzada con coordenas SVG...imposible...entonces para ese caso se hace un programita que te permita dibujar con el cursor mientras debajo corre todo el codigo... lo veo bien, util y necesario
#50
Cita de: tincopasan en  5 Agosto 2019, 04:27 AM
supongo que es como en todo, depende de cada uno creer que es mejor o peor según su prespectiva.
ahora tu planteo parece que solo intenta ofenderclaro porque es mentira que sea más rápido, o simple o vaya a saber que cosa.no sé si sabrás que la rueda ya está inventada, la próxima vez que uses un vehículo como un fin, ponete a construirlo vos, desde 0, no seas flojo o mediocre. No me interezan la mayoría de los lenguajes que has mencionado, salvo java(que puedo considerarlo un lenguaje de programación) todos los otros(html,php,etc)¿de verdad pensás que son lenguajes de programación?
aparte de altruista, sos adivino y sicólogo.
si querés elegir como laburar en lo que sea, no es necesario agredir el trabajo de otros, que cada uno haga el suyo, como pueda o como se le de la gana.
¿o estás buscando que apoyen tus ideas?
el tema no es malo, tu forma de planteo me parece de un infante.

1. No es por ofender.

2. Inventaria un vehiculo totalmente desde cero si me dedicara a ello. De la misma forma haria mis propios diseños moviles o sistema operativo si me dedicara a eso. No podemos inventar desde cero todo lo que nos rodea (ni el mas genio lo haria), pero si lo que es nuestra especialidad.

3. Esta bien que no te interesen los lenguajes que he mencionado, a mi tampoco me interesan los otros lenguajes, porque no me gusta hacer aplicaciones moviles ni de escritorio..lo mio es la web.

4. No busco que apoyen mis ideas, solo diversas opiniones. Creo que ya estamos grandecitos como para ofendernos por una cosa asi. Si he dicho lo que dicho es porque es verdad, asi esta el mundo, asi estan los "profesionales".

5. A veces hay que reinventar la rueda para hacerlo a nuestro gusto al 100% y para que no haya codigo basura y cosas sobrantes que nunca vamos a utilizar. Justamente ese es otro de los argumentos de los fanaticos de estas tecnologias "no hay que reinventar la rueda"...no sabes cuantas veces he escuchado esa frase trillada.

6. Por ultimo yo no estoy en contra de que las capacidades de un lenguaje se amplien , siempre y cuando sea algo OFICIAL, no algo creado por cualquiera, que encima te acostumbra a hacer malas practicas.

extra:
Html5 y Css3 entran en la categoria de lenguajes informaticos , de hecho hasta programas de edicion de video o graficos tienen debajo codigos de estos lenguajes.