Nopues, para los wintenderos usen photoshop xD

Pues ahi tienes un problema ya que estas escapando o limpiando la contraseña y luego creando el hash, eso quiere decir que el hash equivale a la contraseña limpiada y eso puede provocar problemas al momento de intentar acceder después.

Saludos.

Hola, si en parte, porque usas stripslashes? antiguamente php lo necesitaba pero eso ya no se hace, las versiones de php 5 en adelante ya no agregan los backslashes en los parámetros.

Ojo, usa el trim en cada situación, no de manera genérica, por ejemplo si usas trim para guardar el valor binario del hash de una contraseña puede que elimine algunos bytes.

Mejor usa cada función de manera directa en cada caso en ves de crear una función que retorna otra función, así te acostumbras a utilizar las funciones nativas de php.

Si vas a usar php puedes probar codeigniter y active record, de esa manera no necesitarás crear las consultas sql de manera manual y tu aplicación será compatible con distintos tipos de bases de datos.

Saludos.

Hola, muchas personas cometen el mismo error, tu función tiene vulnerabilidades.

Las inyecciones SQL se previenen escapando los caracteres cuando son ejecutadas las consultas sql, los xss se previenen utilizando htmlentities, pero cuando unes ambas cosas, por ejemplo, un filtro de inyección sql para evitar un xss o un filtro de xss para evitar una inyección sql abre agujeros de seguridad porque las funciones no están diseñadas para eso.

Debes utilizar cada función de filtro en su caso en particular. Cuando vayas a consultar vía SQL debes escapar caracteres con mysql_real_escape_string() o parametrizar, cuando vayas a exponer información hacia afuera en una pagina html debes usar htmlepecialchars(), si vas a escapar en una dirección url debes usar urlencode() y así.

Saludos.

Hablando en temas de estándares la eñe tiene una posición binaria muy alejada del alfabeto normal que es a-z, de hecho en expresiones regulares decir a-z no incluye necesariamente letras con acentos o eñes, según latin iso y utf8 esos caracteres son considerados símbolos y no letras. Asi que, si tu software intenta ordenar estos caracteres de manera nativa te dará muchos problemas.

Entonces, ¿cómo considerar la eñe como alfabeto?: SQL como estandar, ya sea mysql, sql server o postgresql las eñes y acentos son considerados dentro del alfabeto como letras sin acento, esto quiere decir que realizar una búsqueda de "día" con acento tendrá el mismo resultado que "dia" sin acento. Para lograr esto SQL no utiliza el alfabeto normal estandarizado sino que lo incluye como parte de un tipo de conjunto de caracteres de tipo ascii personalizado.

Para llevar a la práctica esto deberás crear una lista de caracteres que tu software considerará como alfabeto y luego realizar el ordenamiento según el valor de índice de tu arreglo, que por ejemplo puede ser un const char array y luego hacer un for a cada uno e irlo inyectando a un segundo arreglo donde cada llave de índice es igual al índice de tu lista de caracteres y el valor es igual a la cantidad de caracteres existentes, luego simplemente escribes cada caracter según la cantidad dictada por ese segundo arreglo.

El problema de esto es que las letras con acento y eñes tienen un valor binario distinto según cada codificación de caracteres, en cambio el alfabeto normal siempre es el mismo valor (si, cuando crearon el sistema numérico en el alfabeto no pensaron en otro lenguaje que no fuera el inglés), por esto existen las funciones para codificar y decodificar textos en diferentes tipos de codificación de caracteres, justamente para transformar el valor binario de un caracter a otro valor equivalente.

En este caso lo que te recomiendo es que uses c++ y stdlib para procesar strings y no caracteres a nivel binario sino tendrás que reinventar la rueda intentando crear funciones y mapas de los valores de cada caracter y símbolo, luego usas algún diccionario o ordenador de alto nivel que use strings según la codificación actual de tu software y ya.

Recuerda que si vas a procesar y a guardar textos debes fijar una misma codificación de caracteres para todo, esto quiere decir, que si vas a procesar todo como utf8 tu base de datos o textos a guardar también deben estar en utf8 o si no tus acentos se verán con símbolos de euro en ves de letras. También debes considerar la codificación de caracteres de entrada según la consola de cada usuario, por ejemplo yo acostumbro a usar utf8 pero mucha gente de latinoamérica tiene sus consolas configuradas para latin iso y los valores binarios de las letras con acentos y eñes cambia.

Saludos.

Normalmente cada punto de las reglas son de sentido común, o sea, está claro que si haces un post sólo para hablar mal de una persona y de manera racista es porque el post debe ser borrado y la persona amonestada.

Antiguamente las reglas no eran tan explícitas, eran mucho mas cortas y de sentido común, el problema es que con los años ha entrado muchos trolls con ganas de molestar y hacer lo que por sentido común no se debe hacer, y luego alegan que eso no estaba en las reglas, asi que progresivamente con el tiempo hemos ido ajustando las reglas para ser bien explícitos y puntuales con cada tema para que luego no digan que no estaba en las reglas.

Si eres una persona con un buen sentido común no deberían importarte las reglas ya que nunca hemos aplciado alguna norma especial fuera de lo normal, la finalidad de todo lo que se escribe está en mantener el respeto mútuo, ser ordenado, tener cuidado con los temas que puedan afectar al foro de manera legal, etc.

Claro, si haces un post y tienes problemas con las reglas es porque tu sentido común no es bueno y debes leer las reglas, generalmente eso se aplica a personas menores de edad que les cuesta saber el significado de respeto y jerarquía. Así como en todas las comunidades y también en un trabajo, existe gente que está a cargo y a su ves gente que está a cargo de esos que están a cargo y ellos velan porque todo se mantenga bien para que la comunidad siga recibiendo usuarios nuevos y como en todo lugar, se debe respetar las desiciones del lugar donde estás, vamos, eso es sentido común y se aplica a todo incluyendo dentro de nuestras mismas casas.

Saludos.

Puedes utilizar websocket sin la necesidad de utilizar bases de datos, asi puedes saber cuando un usuario está en línea o no, enganchas cada item de usuario a un id de evento distinto y lanzas una conexión de un solo websocket y ya.

Saludos.

Todo depende del punto de vista, pero en resumen puedo decir que efectivamente los sistemas cms por lo general son mas vulnerables que otras alternativas.

Si comparas un CMS con un desarrollo hecho de cero, dependiendo de la calidad puede que el sistema cms sea mucho mejor que el sistema hecho de cero, por otro lado si el equipo de trabajo es profesional y la aplicación está bien diseñada entonces será menos vulnerable que un sistema cms conocido.

Por lo general los sistemas cms están diseñados para ser lo más genéricos posible y es ahí donde recae la mayoría de los problemas, por ejemplo, al ser un sistema tan genérico necesitarás de plugins o componentes adicionales externos y muchos de ellos sin un control de seguridad. En cambio un sistema propio estará diseñado para lo que debe hacer unicamente y si su arquitectura es robusta, escalable y segura entonces conviene más.

Saludos.

Sólo busca como convertir de manera masiva los xml a csv y luego los importas utilizando bulk load directamente desde SQL:

https://docs.microsoft.com/en-us/sql/t-sql/statements/bulk-insert-transact-sql?view=sql-server-2017

Igual dependerá de que tipo de servidor uses, por ejemplo, si utilizas sql server es porque usas windows server, por lo cual te conviene crear un proyecto en c# que haga el trabajo de procesamiento e importación utilizando un modelo de datos simple y una conexión directa a la base de datos (siempre y cuando no sea un proyecto grande, sino tendrás que crear una integración para la capa de datos de tu proyecto).

Saludos.

Lo mas probable es que sea el caché del cloudflare.