Mensajes

Los issues se cierran cuando dejan de ser "un issue" (un problema).

No creo que te hayas equivocado, esa consulta de los LIMIT :x, :y no funciona a no ser que concatene LIMIT '.($x).', '.($y)

No sé si se podría arreglar esta vulnerabilidad de inyecciones para estas variables que quedarán concatenadas, con alguna función para "limpiar". Para este caso puedo decir si es numerico x e y pero ya cuando la variable es una cadena se complica.

Hay ejemplos en SO donde si funciona, pero tienes que especificar PDO::PARAM_INT al parámetro con PDOStatement::bindValue. En la misma documentación de MySQL hace mención que esto es posible. No veo porque el driver no lo habría de tomar en cuenta.

Al parecer creo que eso es posible. Creo que me equivoque cuando dije que solo podemos parametrizar valores... sobre todo cuando emulas los prepared statements. Pero al parecer nombres de columnas (o al menos usar un placeholder para multiples columnas) no es posible.

No creo que puedas parametrizar esa parte de la query. Hasta donde yo tengo entendido solo los valores, no los campos. Quizás se pueda hacer algo con la tabla de metadatos de MySQL pero no lo recomendaría.

El error sin embargo es porque PDO::setAtribute regresa true/false, así que ahí te cargas $query. Simplemente no guardes el resultado de esa función en $query... pero como te dije, no creo que puedas parametrizar esa parte de la query.

Y de la otra forma tienes que estar completamente seguro del contenido de $by porque ahí fácilmente tienes SQLi.

se que para desarrollar microservicios lo ideal es python que entorno de desarrollo debo tener disponible?

xq ejemplo antes de mi trabajo actual usaba visual studiocode, angular, node.js. mongodb, bootstrap, javascrit, typescript y eso.

en este caso que quiera desarrollar aplicaciones web 'monoliticas'  y con 'microservicios' con python que herramientas debo tener??

por ahi me fui guiando: VSC, DJANGO  y no se que mas, si  me pasan un curso intensivo se los agradezco 

Pues a decir verdad todas esas son herramientas que también podrías utilizar en microservicios con backend en python. Angular, Node.js, Bootstrap, javascript y TypeScript se pueden utilizar para el front end de tu  microservicio. Lo único que vas a necesitar realmente es un framework de python como Django.

Node.js funciona igual para microservicios por lo general. Realmente podrías usar lo que quieras... un microservicio con Spring, otro con Django, otro con MERN, etc...

Estoy haciendo la petición desde https://latam.nombreorganizacion.com/mex/ y el destino sería https://latam.nombreorganizacion.com/compl/geting.php
Y mencionas de usar la cabecera de access-control-allow-origin, esto ya lo hice pero si me pudieras confirmar que lo estoy haciendo bien la cabecera la puse por encima de todo el código del archivo geting.php y sigue sin funcionar, también metí en el htaccess lo siguiente
Y me arroja el mismo error con todo.

Este es el mismo origen.

Los dos usan https, los dos tienen el mismo dominio y están usando el mismo puerto (por defecto https es 443). Así que no deberías tener ese error (porque es el mismo origen).

¿Estás seguro que uno de estos servidores no está usando HTTP en lugar de HTTPS? Desde la página que hace la petición AJAX, abre la consola y escribe:

Código (javascript) [Seleccionar] Expandir

window.origin

Si no es exactamente igual al host destino, estás intentado hacer una petición de origen cruzado.

El error básicamente dice que el origen no concuerda.

Si la página que esta haciendo la petición con jQuery tiene un origen de:

https://www.dominio.com

Y un destino de:

https://dom.dominio.com

Entonces se dice que la petición está cruzando el origen. Si la petición cruza el origen, el origen destino tiene que permitir peticiones al origen fuente (por cuestión de seguridad). Sería cuestión de configurar el servidor en el origen destino para hacer esto (tienes que usar la cabecera access-control-allow-origin)

Si se me permite un inciso, y por lo que sé, todos los punteros en C (repito: punteros) tienen el mismo tamaño: un tamaño capaz de guardar una dirección de memoria.
Otra cosa es el tipo del puntero: éste le dice al compilador el tamaño del dato al que se apunta para que cuándo se dereferencíe tome tantos bytes de la memoria a partir de la dirección del puntero para trabajar con él.
Es decir, un puntero en sí da igual que sea int, long, unsigned, o una función de muchos parámetros, es solo una dirección de memoria.
Por eso el void* puede convertirse en cualquier cosa, porqué únicamente guarda la información de la dirección, no del tamaño del dato y por eso el compilador necesita el cast, para saber cuántos bytes toma el dato que se guarda allí.
En los sistemas en modo real un puntero puede apuntar a cualquier sitio: a la memoria gráfica, a alguna parte del sistema operativo, a otros programas... y lo peor es que dejaba escribir allí. Por eso durante tanto tiempo los punteros eran una cosa muy temida, no académicamente, sino porqué podían causar auténticos desastres. También los virus tenían más acceso a la máquina.
Ahora con las protecciones propias del procesador y del sistema operativo un puntero mal dirigido lo único que puede conseguir es que el sistema cierre el programa.

Hasta donde yo se no hay ninguna garantía que un programa en C pueda usar un puntero void* para almacenar punteros a funciones (los punteros de funciones pueden usar otro tipo de direccionamiento). Había un apartado en la especificación en la que dejaba esto en claro. Hay otros estándares y extensiones que quizás puedan agregar esa limitación pero al menos el estándar en C no ofrece esa garantía.

Esto ya se sale fuera del tema.

Iba a decir... que las fotos son de gorillas y el texto habla de un orangutan pero bueno, por lo menos también habla de gorillas...

Es lo mismo que con cualquier ransomware, nadie recomendaría pagar un rescate, mucho menos por 50 millones.