huge
v3.3.1: Merge pull request #877 from sr-verde
Solo una solución simple de autenticación de usuario dentro de un esqueleto de marco súper simple que funciona de inmediato (y viene con un instalador automático), utilizando la implementación oficial de hash/salting de contraseñas de bcrypt preparada para el futuro de PHP 5.5+, además algunas características interesantes que acelerarán drásticamente el tiempo desde la idea hasta el primer prototipo de aplicación utilizable. Nada más. Este proyecto se centra en la simplicidad extrema. Todo es lo más sencillo posible, pensado para proyectos más pequeños, trabajos típicos de agencia y borradores rápidos. Si desea crear aplicaciones corporativas masivas con todas las características que tienen los marcos modernos, eche un vistazo a Laravel, Symfony o Yii, pero si solo desea crear rápidamente algo que simplemente funcione, entonces este script podría ser interesante para usted.
La arquitectura lo más simple posible de HUGE se inspiró en varias charlas de conferencias, diapositivas y artículos sobre aplicaciones enormes que, sorprendente e intencionalmente, regresan a los conceptos básicos de la programación, utilizando programación procedimental, clases estáticas, construcciones extremadamente simples, no totalmente DRY. código, etc. manteniendo el código extremadamente legible (StackOverflow, Wikipedia, SoundCloud).
Algunas palabras de moda interesantes en este contexto: KISS, YAGNI, Feature Creep, Producto mínimo viable.
Para mantener este proyecto estable, seguro, limpio y mínimo, he decidido reducir el desarrollo de HUGE al mínimo. No se preocupe, esto en realidad es algo bueno: las nuevas funciones generalmente significan nuevos errores, muchas pruebas, correcciones, incompatibilidades y, para algunas personas, incluso un gran estrés por las actualizaciones. Como HUGE es un script crítico para la seguridad, las nuevas características no son tan importantes como un núcleo estable y seguro, es por eso que la gente lo usa. Esto significa:
Y para ser honesto, mantener un marco de forma gratuita en mi poco tiempo libre tampoco es lo que quiero hacer de forma permanente. :)
Finalmente, una pequeña nota: el mundo PHP ha evolucionado dramáticamente, tenemos excelentes marcos con características increíbles y grandes equipos profesionales detrás, documentaciones muy bien escritas y grandes comunidades, por lo que simplemente no hay razón para trabajar mucho en otro marco. En su lugar, comprométase con los marcos populares, entonces su trabajo tendrá mucho más impacto y será utilizado por mucha más gente.
Gracias a todos los que están alrededor de este proyecto, ¡que lo paséis genial! XOXO, Chris
En 2010/2011 no había soluciones de inicio de sesión útiles en el mundo PHP, al menos no para los no expertos. Así que cometí el peor error que comete todo desarrollador joven: intentar crear algo yo solo sin tener ni idea de los conceptos básicos de seguridad. Lo que lo empeoró aún más fue: la web estaba (y está) llena de tutoriales totalmente defectuosos sobre cómo crear sistemas de autenticación de usuarios, incluso las empresas más grandes del mundo lo hicieron completamente mal (aquí estamos hablando de SONY, LinkedIn y Adobe), y Además, muchos marcos importantes en todos los grandes lenguajes de programación (!) utilizaban tecnologías de guardado de contraseñas totalmente obsoletas e inseguras.
Sin embargo, en 2012, el experto en seguridad Anthony Ferrara publicó una pequeña biblioteca PHP, que permite un hash de contraseñas extremadamente seguro, moderno y correcto en PHP 5.3 y 5.4, utilizable por todos los desarrolladores sin ningún estrés y sin ningún conocimiento sobre los aspectos internos de seguridad. El script fue tan asombroso que fue escrito en el núcleo de PHP 5.5, es el estándar de facto en estos días.
Cuando salió esto, intenté usar esta biblioteca básica para construir un sistema de inicio de sesión listo para usar y completamente funcional para varios proyectos privados y comerciales, y puse el código en GitHub. Mucha gente encontró esto útil, contribuyó y corrigió errores en el proyecto, hizo bifurcaciones, versiones más pequeñas y más grandes. El resultado es este proyecto.
Tenga en cuenta: ahora, en 2015, la mayoría de los marcos principales tienen una excelente lógica de autenticación de usuario integrada de forma predeterminada. Este no era el caso hace años. Entonces, desde la perspectiva actual, podría ser más inteligente elegir Laravel, Yii o Symfony para proyectos serios. Pero siéntete libre de probar HUGE, el instalador automático pondrá en marcha una instalación completamente funcional en cuestión de minutos y sin ninguna configuración.
¿Y por qué el nombre "ENORME"? Es una buena combinación con TINY, MINI y MINI2, MINI3, que son algunos de mis otros proyectos más antiguos. Micro frameworks súper mínimos para un desarrollo extremadamente rápido y sencillo de sitios web sencillos.
Vea una demostración en vivo de la versión anterior 3.0 aquí y el phpinfo() del servidor aquí.
Hay mucho trabajo detrás de este proyecto. Podría ahorrarle cientos, tal vez miles de horas de trabajo (calcule eso en costos de desarrollador). Entonces, cuando gane dinero usando HUGE, sea justo y devuelva algo al código abierto. HUGE es totalmente gratuito para uso privado y comercial.
Apoye el proyecto alquilando un servidor en DigitalOcean o simplemente dando una propina a un café en BuyMeACoffee.com. ¡Gracias! :)
También siéntete libre de contribuir a este proyecto.
Con licencia del MIT. Totalmente gratis para proyectos privados o comerciales.
Asegúrese de conocer los conceptos básicos de la programación orientada a objetos y MVC, de poder utilizar la línea de comandos y de haber utilizado Composer antes. Este script no es para principiantes.
Yo, completamente automático. Por qué ? Porque siempre odié pasar días intentando descubrir cómo instalar algo. Esto le ahorrará mucho tiempo y nervios. Dona un café si te gusta.
Si está utilizando Vagrant para su desarrollo, simplemente
vagrant box add ubuntu/trusty64vagrant up en esa carpeta.5 minutos más tarde tendrás un ENORME dentro de Ubuntu 14.04 LTS completamente instalado. El código completo se sincronizará automáticamente con la carpeta actual. La contraseña raíz de MySQL y la contraseña raíz de PHPMyAdmin están configuradas en 12345678 . Por defecto, 192.168.33.111 es la IP de su nueva caja.
Instalación extremadamente simple en un servidor Ubuntu 14.04 LTS típico, nuevo y simple:
Descargue el script del instalador
wget https://raw.githubusercontent.com/panique/huge/master/_one-click-installation/bootstrap.shHazlo ejecutable
chmod +x bootstrap.sh¡Ejecútalo! Dale unos minutos para realizar todas las tareas. Y sí, puedes agradecerme más tarde :)
sudo ./bootstrap.shComposer install en la carpeta raíz de la aplicación para instalar las dependencias¿"El correo electrónico no funciona"? Consulte la solución de problemas a continuación. HACER
¡Esta es sólo una guía rápida para una fácil configuración de un entorno de desarrollo!
Asegúrese de tener instalado Apache, PHP 5.5+ y MySQL. Tutorial aquí. Seguramente Nginx también funcionará, pero aún no hay pautas de instalación disponibles.
Edite vhost para hacer posible URL limpias y dirigir todo el tráfico a la carpeta /public de su proyecto:
sudo nano /etc/apache2/sites-available/000-default.confy hacer que el archivo se vea como
<VirtualHost *:80>
DocumentRoot "/var/www/html/public"
<Directory "/var/www/html/public">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Habilite mod_rewrite y reinicie Apache.
sudo a2enmod rewrite
service apache2 restartInstale curl (necesario para usar git), openssl (necesario para clonar desde GitHub, ya que github es solo https), PHP GD, la biblioteca gráfica (creamos captchas y avatares) y git.
sudo apt-get -y install curl
sudo apt-get -y install php5-curl
sudo apt-get -y install openssl
sudo apt-get -y install php5-gd
sudo apt-get -y install gitgit clon ENORME
sudo git clone https://github.com/panique/huge " /var/www/html "Instalar compositor
curl -s https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composerVaya a la carpeta del proyecto, cargue los paquetes de Composer (--dev es opcional, ya conoce el trato)
cd /var/www/html
composer install --devEjecute las sentencias SQL. A través de phpmyadmin o mediante la línea de comando, por ejemplo. 12345678 es la contraseña de ejemplo. Tenga en cuenta que esto está escrito sin espacios.
sudo mysql -h " localhost " -u " root " " -p12345678 " < " /var/www/html/application/_installation/01-create-database.sql "
sudo mysql -h " localhost " -u " root " " -p12345678 " < " /var/www/html/application/_installation/02-create-table-users.sql "
sudo mysql -h " localhost " -u " root " " -p12345678 " < " /var/www/html/application/_installation/03-create-table-notes.sql "Haga que se pueda escribir en la carpeta del avatar (¡asegúrese de que sea la ruta correcta!)
sudo chown -R www-data " /var/www/html/public/avatars "Si esto no funciona para usted, puede intentarlo de la manera más difícil configurando alternativamente
sudo chmod 0777 -R " /var/www/html/public/avatars "Eliminar el archivo de demostración predeterminado de Apache
sudo rm " /var/www/html/index.html "Edite la configuración de la aplicación en application/config/config.development.php e ingrese las credenciales de su base de datos.
Última parte (no es necesaria para una primera prueba): configure sus credenciales SMTP en el mismo archivo y establezca EMAIL_USE_SMTP en verdadero, para que pueda enviar correos electrónicos adecuados. ¡Se recomienda encarecidamente utilizar SMTP para enviar correo! El envío nativo a través del correo PHP() no funcionará en casi todos los casos (bloqueo de spam). Yo uso SMTP2GO.
Luego verifique la IP/dominio de su servidor. Todo debería funcionar bien.
Esta es una configuración NGINX no probada. Por favor comente el ticket si ve problemas.
server {
# your listening port
listen 80;
# your server name
server_name example.com;
# your path to access log files
access_log /srv/www/example.com/logs/access.log;
error_log /srv/www/example.com/logs/error.log;
# your root
root /srv/www/example.com/public_html;
# huge
index index.php;
# huge
location / {
try_files $uri /index.php?url=$uri&$args;
}
# your PHP config
location ~ .php$ {
try_files $uri = 401;
include /etc/nginx/fastcgi_params;
fastcgi_pass unix:/var/run/php-fastcgi/php-fastcgi.socket;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
Muchas gracias a razuro por esta excelente configuración: coloque esto dentro de su carpeta raíz, pero no coloque ningún web.config en su carpeta pública.
<?xml version="1.0" encoding="UTF-8"?><configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Imported Rule 1" stopProcessing="true">
<match url="^(.*)$" ignoreCase="false" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" ignoreCase="false" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsFile" ignoreCase="false" negate="true" />
</conditions>
<action type="Rewrite" url="public/index.php?url={R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Encuentre el boleto original aquí.
Por defecto hay dos usuarios de demostración, un usuario normal y un usuario administrador. Para obtener más información al respecto, consulte la parte de rol de usuario del pequeño bloque de documentación dentro de este archivo Léame.
Usuario normal: el nombre de usuario es demo2 , la contraseña es 12345678 . El usuario ya está activado. Usuario administrador (puede eliminar y suspender a otros usuarios): el nombre de usuario es demo y la contraseña es 12345678 . El usuario ya está activado.
Hay varios archivos en la carpeta raíz del proyecto que pueden resultar irritantes:
README y CHANGELOG se explican por sí solos.
Se está preparando una documentación real. Hasta entonces, eche un vistazo al código y utilice las funciones de finalización de código de su IDE para tener una idea de cómo funcionan las cosas. Es bastante obvio cuando observa los archivos del controlador, los archivos del modelo y cómo se muestran los datos en los archivos de vista. Lamento mucho que todavía no haya documentación, pero el tiempo es escaso y todos hacemos esto gratis en nuestro tiempo libre :)
Actualmente existen dos tipos de usuarios: usuarios normales y administradores. Son exactamente iguales, pero...
Los usuarios administradores pueden eliminar y suspender a otros usuarios, tienen un botón adicional "admin" en la navegación. Los usuarios administradores tienen un valor de 7 dentro del campo de la tabla de la base de datos user_account_type . No pueden actualizar ni degradar sus cuentas (ya que esto no tendría sentido).
Los usuarios normales no tienen funciones de administración con seguridad. Pero pueden actualizar y degradar sus cuentas (pruébelo a través de /user/changeUserRole), que es básicamente una implementación súper simple del concepto de usuario básico/usuario premium. Los usuarios normales tienen un valor de 1 o 2 dentro del campo de la tabla de la base de datos user_account_type . De forma predeterminada, todos los nuevos usuarios registrados son usuarios normales con el rol de usuario 1.
Consulte la sección "Pruebas con usuarios de demostración" de este archivo Léame para obtener más información.
También hay una solicitud de extracción muy interesante que agrega roles de usuario y permisos de usuario, que no está integrada en el proyecto porque es demasiado avanzada y compleja. Pero esto podría ser exactamente lo que necesitas, no dudes en intentarlo.
Para evitar ataques CSRF, HUGE lo hace de la forma más común: utilizando un token de seguridad cuando el usuario envía formularios críticos. Esto significa: Cuando PHP procesa un formulario para el usuario, la aplicación coloca una "cadena aleatoria" dentro del formulario (como un campo de entrada oculto), generada mediante Csrf::makeToken() (application/core/Csrf.php), que también guarda este token en la sesión. Cuando se envía el formulario, la aplicación verifica si la solicitud POST contiene exactamente el token del formulario que se encuentra dentro de la sesión.
Esta característica de prevención CSRF se implementa actualmente en el proceso del formulario de inicio de sesión (consulte application/view/login/index.php ) y en el proceso del formulario de cambio de nombre de usuario (consulte application/view/user/editUsername.php ), la mayoría de los demás formularios no son de seguridad. crítico y debe ser lo más simple posible.
Entonces, para hacer esto con un formulario normal, simplemente: En su formulario, antes del botón de enviar, coloque: <input type="hidden" name="csrf_token" value="<?= Csrf::makeToken(); ?>" /> Luego, en la acción del controlador, valide el token CSRF enviado con el formulario haciendo:
// check if csrf token is valid
if (!Csrf::isTokenValid()) {
LoginModel::logout();
Redirect::home();
exit();
}
¡Muchas gracias a OmarElGabry por implementar esto!
En teoría: sí, pero esta característica no funcionó en mis pruebas. Como es una característica externa, consulte el ticket correspondiente para obtener más información.
Hay algunas funciones increíbles o ideas de funciones creadas por personas increíbles, pero estas funciones son de interés demasiado especial para incluirlas en la versión principal de HUGE, pero eche un vistazo a estos tickets si está interesado:
La idea de este proyecto es y era proporcionar una aplicación básica súper simple con un sistema de autenticación de usuario completo en su interior que funcione bien y sea estable. Debido a la naturaleza altamente relacionada con la seguridad de este script, cualquier cambio significa mucho trabajo, muchas pruebas, detectar casos extremos, etc., y al final pasé el 90% del tiempo probando y arreglando nuevas funciones o nuevas funciones que rompen las existentes. cosas, y hacer esto realmente no es lo que nadie quiere hacer gratis en su poco tiempo libre :)
Para mantener el proyecto estable, limpio y fácil de mantener, me gustaría anunciar el "final suave de la vida útil" de este proyecto, es decir:
A. HUGE no obtendrá ninguna característica nueva en el futuro, pero... B. Se realizarán correcciones y correcciones de errores, probablemente durante años.
Mientras HUGE estaba en desarrollo, hubo 3 reglas principales que me ayudaron a mí (y probablemente a otros) a escribir un código mínimo, limpio y funcional. Quizás también te resulte útil:
Como se indicó en la introducción de este README, también hay algunos conceptos poderosos que pueden ayudarlo a desarrollar cosas interesantes: KISS, YAGNI, Feature Creep, Producto mínimo viable.
Para evitar trabajo innecesario para todos nosotros, recomendaría amablemente a todos que usen HUGE para proyectos simples que solo necesitan las características que ya existen, y si realmente necesitan una arquitectura RESTful, migraciones, enrutamiento, 2FA, etc., entonces es más fácil, más limpio y más rápido simplemente usar Laravel, Symfony o Zend.
Sin embargo, aquí están las posibles características sugeridas por la comunidad, extraídas de muchos tickets. Siéntete libre de implementarlos en tus bifurcaciones del proyecto:
Hubo dos (!) foros de soporte para v1 y v2 de este proyecto (ENORME es v3), y ambos fueron vandalizados por personas que ni siquiera leyeron el archivo Léame y/o las pautas de instalación. La pregunta más frecuente fue "el script no funciona, por favor ayuda" sin proporcionar ninguna información útil (como el código o la configuración del servidor o incluso la versión utilizada). Mientras escribo estas líneas alguien acaba de preguntar vía Twitter "cómo instalar sin Composer". Ya sabes a lo que me refiero :) - El 99% de las preguntas no serían necesarias si las personas hubieran leído las pautas, hubieran hecho una investigación mínima por su cuenta o hubieran dejado de complicar las cosas innecesariamente. E incluso cuando escribieron respuestas detalladas, la mayoría de ellos todavía lo estropearon, lo que resultó en desvaríos y quejas (¡para soporte gratuito para un software gratuito!). Fue simplemente frustrante lidiar con esto todos los días, especialmente cuando la gente da por sentado que es deber de los desarrolladores de código abierto brindar soporte detallado, gratuito y personal para cada solicitud de "ayuda por favor".
Entonces decidí detener por completo cualquier soporte gratuito. Si tiene preguntas serias sobre problemas reales dentro del script, utilice la función de problemas de GitHub.
Palabras duras, pero como básicamente todos los proyectos públicos de Internet son acosados, destrozados y controlados hoy en día por personas muy extrañas, es necesario: algunas reglas simples.
Respeto que esto es sólo un simple guión escrito por voluntarios no remunerados en su tiempo libre. Este NO es un software empresarial que haya comprado por 10.000 dólares. No hay razón para quejarse (!) del software gratuito de código abierto. La actitud contra el software libre es realmente frustrante hoy en día, la gente da todo por sentado sin darse cuenta del trabajo que hay detrás y del hecho de que obtienen software serio totalmente gratis, ahorrando miles de dólares. Si no te gusta, no lo uses. Si desea una función, intente participar en el proceso, ¡tal vez incluso constrúyala usted mismo y agréguela al proyecto! Sea amable y respetuoso. ¡La crítica constructiva siempre es bienvenida!
No golpees, no odies, no envíes spam, no destroces. Por favor, no solicite soporte personal gratuito, no pregunte si alguien podría hacer su trabajo por usted. Antes de preguntar algo, asegúrese de haber leído el archivo README, haber seguido todos los tutoriales, haber verificado dos veces el código y haber intentado resolver el problema usted mismo.
Los trolls y las personas muy molestas obtendrán una prohibición/bloqueo permanente. GitHub tiene un equipo antiabuso muy poderoso.
Confirme solo en la rama de desarrollo . La rama master siempre contendrá la versión estable.
Scrutinizer (rama maestra), Scrutinizer (rama de desarrollo), Code Climate, Codacy, SensioLabs Insight.
Debido a las posibles consecuencias al publicar un error en un proyecto público de código abierto, le pido amablemente que envíe errores realmente importantes a mi dirección de correo electrónico, sin publicarlos aquí. Si el error no es interesante para los atacantes: no dudes en crear un problema normal en GitHub.
Vea los problemas activos aquí: https://github.com/panique/huge/issues?state=open
Problema interesante: cuando un usuario accede a su sitio web, el navegador del usuario también solicitará uno o más (!) favicons (de diferentes tamaños). Si estos archivos estáticos no existen, su aplicación comenzará a generar una respuesta 404 y una página 404 para cada archivo. Esto desperdicia mucha energía del servidor y también es inútil, por lo tanto, asegúrese de tener siempre favicons o manejar esto desde el nivel Apache/nginx.
¡HUGE intenta manejar esto enviando una imagen vacía en el encabezado de view/_templates/header.php!
Más información dentro de este ticket: Devuelva el 404 correspondiente si falta favicon.ico, imágenes faltantes, etc.
Más aquí en Stackflow: ¿Cómo evitar las solicitudes de favicon.ico? ¿No es una tontería que un pequeño favicon requiera otra solicitud HTTP? ¿Cómo hacer que un favicon entre en un sprite?
También estoy escribiendo un blog en Dev Metal .
