Mensajes

Esas cabeceras las deberías de aplicar en tu servidor http, vease, apache, nginx litespeed etc... no en PHP ... puesto que estas añadiendo una sobrecarga y solo lo aplicas a archivos PHP.

Saludos

@Aguijon_zerO parece ser el vivo ejemplo de la conversación que nos comparte @Machacador  

Saludos

https://getbootstrap.com/docs/4.1/content/tables/
https://getbootstrap.com/docs/4.1/utilities/borders/

Saludos

Porque si te molestas en releerme desde el principio... de eso es de lo que iba mi (intento de) contribución.

Pues bien, vamos a tu primer post en este tema.

Paso 0. ---> ¿El usuario tiene permisos/credenciales para cambiar la contraseña? Si es que SI ---> IR a paso 1. Si es que NO ---> se le echa fuera.

Un usuario -en general- no tiene porqué tener permisos para cambiar su propia contraseña. A veces es el administrador quien se la da, e incluso se la cambia cada cierto tiempo. Si; sé que es un poco tiquismiquis para redes/sistemas más o menos personales/domésticos, pero en entornos empresariales/corporativos es bastante normal que el usuario/operador de un terminal-PC no tenga privilegios de administrador para cambiar su propia contraseña (o instalar programas o compartir archivos, etc).

Ahí no estás hablando de una contraseña actual, estás hablando de permisos para cambiar su propia contraseña y mencionas como en X entornos es bastante normal (según tú) que el terminal no tenga privilegios para cambiar su propia contraseña. ¿Si o no? Tambien mencionas lo de obligarlo a introducir la contraseña actual, después, es un posdata.

Yo te indique, que el hecho de introducir la contraseña antigua, el compañero ya lo tenía contemplado, tal y como se puede apreciar en el primer post de este tema. Y también hice referencia al tema de los permisos, sobre el cual, di mi opinion:

@Kyrle Eleison, eso ya lo tiene contemplado. Si te fijas, su punto 3 es "Input para pedir contraseña actual".

Otra cosa es lo que has comentado anteriormente de que el usuario debe tener permisos para editar su propia contraseña. A mi esto me parece un error. No se debe impedir cambiar la contraseña. El usuario debe poder introducir y/o cambiar su propia contraseña en cualquier momento. No se me ocurre ningún caso donde sea beneficioso limitar esa capacidad y se me ocurren unos cuantos donde es perjudicial y hasta ilegal.

Saludos

¿Si o no?


Entonces, quizás, deja de estar tan a la defensiva y separa una cosa de otra, pues son dos cosas bien distintas.

¿Y no te parece que, independientemente de quién sea el jefe, se mejora la seguridad de una aplicación proponiendo que para cambiar la contraseña de un usuario PRIMERO se comprube la potestad del usuario para cambiarla, antes de proseguir con el programa? Aunque sólo sea para ahorrar tiempo de ejecución: ¿para qué tomarse la molestia de hacer inputs de contraseña y repetición ANTES de saber si el usuario está capacitado para hacer el cambio? ¿y no al revés?

Porque en un POST (véase petición HTTP), los datos se envian a la vez, no se envian por separado. Porque en cualquier aplicación moderna, la lógica se puede separar y es independiente de la presentación. En este mismo foro, como has mencionado, tienes el ejemplo.

No sé porqué has llevado este post a este punto cuando solamente se trataba de dar una opinión para mejorar.

Me parece genial que tengas una opinión y tal y cuál pascual. Pero esto es un foro y aquí estamos para debatir y para que todos expresemos nuestras opiniones. Tú das tu opinión, yo doy la mía, que puede contradecir la tuya, tú puedes exponer razones o contradecir la mía y así va el proceso. Vamos, lo que es un foro de toda la vida =)

Saludos

Y por supuesto que es legal. Es completamente legal que el dueño de los medios de producción decida cómo, cuando, por quién y en qué condiciones pueden ser utilizados aquellos.

El caso es que el compañero es el que esta desarrollando el entorno. Esto no es un entorno empresarial, es un entorno en desarrollo y el tiene la protestad de decidir que, porque, donde y cuando, no le están imponiendo ninguna condición, si no, ya la habría mencionado.

Que una empresa decida lo que hacer con la información no implica que sea legal o que sea buena practica. No toda la información que almacena una empresa se trata de la misma forma, hay datos amparados por ley que pueden ser protegidos tanto por el cliente como por el trabajador. E incluso fuera del ámbito de datos privados, hay normas mínimas sobre almacenamiento de información y cifrado. Esto es un foro de seguridad, aquí se trata de mejor la seguridad, no de cumplir con las expectativas de un jefe "ignorante".


https://www.boe.es/buscar/act.php?id=BOE-A-2008-979#a93

Saludos

¿Deja la nueva contraseña aunque el propietario no se haya autentificado -al no verificar su contraseña-? ¿Destruye todo el proceso y vuelve al paso 1? ¿No deja ninguna contraseña?

Eso no tiene ningún sentido y dudo que haya siquiera 1 cms que lo haga así. Obviamente verificará la contraseña antigua antes de asignar la nueva. El orden de los inputs de poco importa sobre todo si luego tiene más campos que rellenar.

En una cuenta de empresa o societaria donde es un mero usuario al que otros le han dado permiso, esos otros son los que deciden cual es su contraseña y cómo y para qué puede  usarla... y cuando se la pueden cambiar y comunicárselo.

Insisto. En ningún caso se debe limitar cuando un usuario cambia su contraseña. Es perjudicial para todo el flow de trabajo y es síntoma de problemas de estructura y control en el entorno empresarial. ¿Que pasa si la contraseña del usuario ha sido comprometida y el usuario es el primero en darse cuenta? No la puede cambiar hasta que no avise a sistemas. ¿Que pasa si el usuario quiere llevar por su propia cuenta el cambio periódico de contraseña? La administración debe ser capaz de cambiar la contraseña o resetearla, pero en ningún caso se debe limitar que el usuario pueda cambiar de contraseña... puede ser hasta ilegal.

Saludos

Lo unico que faltaria añadir es asegurarte de que proteges el formulario contra CSRF.

https://owasp.org/www-community/attacks/csrf
https://es.wikipedia.org/wiki/Cross-site_request_forgery


@Kyrle Eleison, eso ya lo tiene contemplado. Si te fijas, su punto 3 es "Input para pedir contraseña actual".

Otra cosa es lo que has comentado anteriormente de que el usuario debe tener permisos para editar su propia contraseña. A mi esto me parece un error. No se debe impedir cambiar la contraseña. El usuario debe poder introducir y/o cambiar su propia contraseña en cualquier momento. No se me ocurre ningún caso donde sea beneficioso limitar esa capacidad y se me ocurren unos cuantos donde es perjudicial y hasta ilegal.

Saludos

No hay problema en postear cosas. La cosa es donde los posteas.

Si solo vas a subir ejecutables, pues al subforo de Software. Si vas a incluir código fuente, pues al subforo del lenguaje en el que esta desarrollado o en su defecto a Programación General.

Saludos

Te está diciendo que el primer parámetro es un boolean y no un recurso. El primer parámetro es $cid que es el resultado de ftp_connect. Ende lo más probable es que ftp_connect te esté retornando un false.

Returns a FTP stream on success or FALSE on error.

Dicho de otro modo, tu servidor FTP no está disponible o PHP no se puede conectar.

Saludos

¿Que paso? ¿Mucho cirilico y poco ruso?  

¿De que coño estas hablando? Te estoy diciendo que te echaste tierra a ti mismo y me vienes a hablar de ruso xDDD


Mira invéntate las mierdas que quieras... las fuentes dicen todo lo contrario, tus propias fuentes dicen lo contrario y eres incapaz de aceptarlo.

Las preguntas eran claras y concisas, sus respuestas se basan en fuentes que tu mismo has puesto. Lo único que estás haciendo ahora es llevar la contraria por no ceder.. allá tu... No engañas a nadie, solo a ti mismo.

Saludos