In the event that someone wanted to change the password by touching the internal configuration file, the program would foresee this, and if it detected such a thing, the tasks related to that Administrator's password could not be displayed.
But if you leave the configuration again with the encrypted password as it was, the backup tasks will continue to run normally.
But in the event that the Administrator himself changed his own password, the tasks related to the administrator password would still be visible perfectly.
Above all, because in pre-events and post-events there may be parameters with sensitive information, when executing scripts, such as access passwords in the parameters themselves.
Especially because the information is precisely confidential and that is why in many cases compressed files are encrypted. But if we use scripts that access, for example, CLOUDS, or MySQL, or places that require passwords, they cannot be accessible so that someone can simply leave the password blank in the internal configuration. And simply with that you can access all the Passwords that are used in the parameters of the programs that are executed in the pre-event and post-event scripts.
----------
Que en el supuesto caso de que alguien quisiera cambiar la contraseña tocando el fichero de configuración interno, el programa lo preveyera, y si detectara tal cosa, no se pudieran visualizar las tareas, que hay relacionadas con la contraseña de ese Administrador.
Pero si vuelve a dejar la configuración con la contraseña encriptada como estaba, se siguieran ejecutando con total normalidad las tareas de backup.
Pero en el caso de que el propio Administrador cambiara su propia contraseña, si siguieran viéndose perfectamente las tareas relacionadas con la contraseña del administrador.
Sobre todo, porque en pre-eventos y post-eventos puede haber parámetros con información sensible, a la hora de ejecutar scripts, como contraseñas de acceso en los propios parámetros.
Sobre todo porque la información precisamente es confidencial y por eso en muchos casos se encriptan los fichero comprimidos. Pero si utilizamos scripts que acceden por ejemplo a NUBES, o a MySQL, o a lugares que requieren contraseñas, no pueden estar al alcance de que alguien simplemente pueda dejar la contraseña en blanco en la configuración interna. Y simplemente con eso poder acceder a todos los Passwords que se utilizan en los parámetros de los programas que se ejecutan en los scripts de pre-eventos y post-eventos.
![:APP]( "Applause")
![:OK]( "OK")
---------
But if you leave the configuration again with the encrypted password as it was, the backup tasks will continue to run normally.
But in the event that the Administrator himself changed his own password, the tasks related to the administrator password would still be visible perfectly.
Above all, because in pre-events and post-events there may be parameters with sensitive information, when executing scripts, such as access passwords in the parameters themselves.
Especially because the information is precisely confidential and that is why in many cases compressed files are encrypted. But if we use scripts that access, for example, CLOUDS, or MySQL, or places that require passwords, they cannot be accessible so that someone can simply leave the password blank in the internal configuration. And simply with that you can access all the Passwords that are used in the parameters of the programs that are executed in the pre-event and post-event scripts.
----------
Que en el supuesto caso de que alguien quisiera cambiar la contraseña tocando el fichero de configuración interno, el programa lo preveyera, y si detectara tal cosa, no se pudieran visualizar las tareas, que hay relacionadas con la contraseña de ese Administrador.
Pero si vuelve a dejar la configuración con la contraseña encriptada como estaba, se siguieran ejecutando con total normalidad las tareas de backup.
Pero en el caso de que el propio Administrador cambiara su propia contraseña, si siguieran viéndose perfectamente las tareas relacionadas con la contraseña del administrador.
Sobre todo, porque en pre-eventos y post-eventos puede haber parámetros con información sensible, a la hora de ejecutar scripts, como contraseñas de acceso en los propios parámetros.
Sobre todo porque la información precisamente es confidencial y por eso en muchos casos se encriptan los fichero comprimidos. Pero si utilizamos scripts que acceden por ejemplo a NUBES, o a MySQL, o a lugares que requieren contraseñas, no pueden estar al alcance de que alguien simplemente pueda dejar la contraseña en blanco en la configuración interna. Y simplemente con eso poder acceder a todos los Passwords que se utilizan en los parámetros de los programas que se ejecutan en los scripts de pre-eventos y post-eventos.
---------
Statistics: Posted by streik — 17 Jul 2024, 14:36