Just a simple user authentication solution inside a super-simple framework skeleton that works out-of-the-box (and comes with an auto-installer), using the future-proof official bcrypt password hashing/salting implementation of PHP 5.5+, plus some nice features that will speed up the time from idea to first usable prototype application dramatically. Nothing more. This project has its focus on hardcore simplicity. Everything is as simple as possible, made for smaller projects, typical agency work and quick drafts. If you want to build massive corporate applications with all the features modern frameworks have, then have a look at Laravel, Symfony or Yii, but if you just want to quickly create something that just works, then this script might be interesting for you.
HUGE's simple-as-possible architecture was inspired by several conference talks, slides and articles about huge applications that - surprisingly and intentionally - go back to the basics of programming, using procedural programming, static classes, extremely simple constructs, not-totally-DRY code etc. while keeping the code extremely readable (StackOverflow, Wikipedia, SoundCloud).
Some interesting Buzzwords in this context: KISS, YAGNI, Feature Creep, Minimum viable product.
To keep this project stable, secure, clean and minimal I've decided to reduce the development of HUGE to a minimum. Don't worry, this is actually a good thing: New features usually mean new bugs, lots of testing, fixes, incompatibilities, and for some people even hardcore update stress. As HUGE is a security-critical script new features are not as important as a stable and secure core, this is why people use it. This means:
- HUGE will not get new features
- but will be maintained, so it will get bugfixes, corrections etc for sure, maybe for years
And to be honest, maintaining a framework for free in my rare free-time is also not what I want to do permanently. :)
Finally a little note: The PHP world has evolved dramatically, we have excellent frameworks with awesome features and big professional teams behind, very well written documentations and large communities, so there's simply no reason to put much work into another framework. Instead, please commit to the popular frameworks, then your work will have much more impact and is used by much more people!
Thanks to everybody around this project, have a wonderful time! XOXO, Chris
- stable v3.1,
- public beta branch: master
- public in-development branch (please commit new code here): develop
- Features
- Live-Demo
- Support
- Follow the project
- License
- Requirements
- Auto-Installation
- Auto-Installation in Vagrant (also useful for 100% reproducible installation of HUGE)
- Auto-Installation in Ubuntu 14.04 LTS server
- Installation (Ubuntu 14.04 LTS)
- Documentation
- Community-provided features & feature discussions
- Future of the project, announcing soft EOL
- Why is there no support forum anymore ?
- Zero tolerance for idiots, trolls and vandals
- Contribute
- Code-Quality scanner links
- Report a bug
Back in 2010/2011 there were no useful login solutions in the PHP world, at least not for non-experts. So I did the worst mistake every young developer does: Trying to build something by myself without having any clue about security basics. What made it even worse was: The web was (and is) full of totally broken tutorials about building user authentication systems, even the biggest companies in the world did this completely wrong (we are talking about SONY, LinkedIn and Adobe here), and also lots of major framework in all big programming languages (!) used totally outdated and insecure password saving technologies.
However, in 2012 security expert Anthony Ferrara published a little PHP library, allowing extremely secure, modern and correct hashing of passwords in PHP 5.3 and 5.4, usable by every developer without any stress and without any knowledge about security internals. The script was so awesome that it was written into the core of PHP 5.5, it's the de-facto standard these days.
When this came out I tried to use this naked library to build a fully working out-of-the-box login system for several private and commercial projects, and put the code on GitHub. Lots of people found this useful, contributed and bugfixed the project, made forks, smaller and larger versions. The result is this project.
Please note: Now, in 2015, most major frameworks have excellent user authentication logic embedded by default. This was not the case years ago. So, from today's perspective it might be smarter to chose Laravel, Yii or Symfony for serious projects. But feel free to try out HUGE, the auto-installer will spin up a fully working installation within minutes and without any configuration.
And why the name "HUGE" ? It's a nice combination to TINY, MINI and MINI2, MINI3, which are some of my other older projects. Super-minimal micro frameworks for extremely fast and simple development of simple websites.
- built with the official PHP password hashing functions, fitting the most modern password hashing/salting web standards
- proper security features, like CSRF blocking (via form tokens), encryption of cookie contents etc.
- users can register, login, logout (with username, email, password)
- password-forget / reset
- remember-me (login via cookie)
- account verification via mail
- captcha
- failed-login-throttling
- user profiles
- account upgrade / downgrade
- simple user types (type 1, type 2, admin)
- supports local avatars and remote Gravatars
- supports native mail and SMTP sending (via PHPMailer and other tools)
- uses PDO for database access for sure, has nice DatabaseFactory (in case your project goes big)
- uses URL rewriting ("beautiful URLs")
- proper split of application and public files (requests only go into /public)
- uses Composer to load external dependencies (PHPMailer, Captcha-Generator, etc.) for sure
- fits PSR-0/1/2/4 coding guidelines
- uses Post-Redirect-Get pattern for nice application flow
- masses of comments
- is actively maintained and bug-fixed (however, no big new features as project slowly reaches End of Life)
- A real documentation (currently there's none, but the code is well commented)
See a live demo of older 3.0 version here and the server's phpinfo() here.
There is a lot of work behind this project. I might save you hundreds, maybe thousands of hours of work (calculate that in developer costs). So when you are earning money by using HUGE, be fair and give something back to open-source. HUGE is totally free to private and commercial use.
Support the project by renting a server at 1&1 or at DigitalOcean. Thanks! :)
Also feel free to contribute to this project.
Licensed under MIT. Totally free for private or commercial projects.
Make sure you know the basics of object-oriented programming and MVC, are able to use the command line and have used Composer before. This script is not for beginners.
- PHP 5.5+
- MySQL 5 database (better use versions 5.5+ as very old versions have a PDO injection bug
- installed PHP extensions: pdo, gd, openssl (the install guideline shows how to do)
- installed tools on your server: git, curl, composer (the install guideline shows how to do)
- for professional mail sending: an SMTP account (I use SMTP2GO)
- activated mod_rewrite on your server (the install guideline shows how to do)
Yo, fully automatic. Why ? Because I always hated it to spend days trying to find out how to install a thing. This will save you masses of time and nerves. Donate a coffee if you like it.
If you are using Vagrant for your development, then simply
- Add the official Ubuntu 14.04 LTS box to your Vagrant:
vagrant box add ubuntu/trusty64 - Move Vagrantfile and bootstrap.sh (from _one-click-installation folder) to a folder where you want to initialize your project.
- Do
vagrant upin that folder.
5 minutes later you'll have a fully installed HUGE inside Ubuntu 14.04 LTS. The full code will be auto-synced with the current folder. MySQL root password and the PHPMyAdmin root password are set to 12345678. By default 192.168.33.111 is the IP of your new box.
Extremely simple installation in a fresh and naked typical Ubuntu 14.04 LTS server:
Download the installer script
wget https://raw.githubusercontent.com/panique/huge/master/_one-click-installation/bootstrap.shMake it executable
chmod +x bootstrap.shRun it! Give it some minutes to perform all the tasks. And yes, you can thank me later :)
sudo ./bootstrap.sh- Make sure you have Apache, PHP, MySQL installed. Tutorial.
- Clone the repo to a folder on your server
- Activate mod_rewrite, route all traffic to application's /public folder. Tutorial.
- Edit application/config: Set your database credentials
- Execute SQL statements from application/_installation to setup database tables
- Install Composer,
run
Composer installon application's root folder to install dependencies - Make avatar folder (application/public/avatars) writable
- For proper email usage: Set SMTP credentials in config file, set EMAIL_USE_SMTP to true
"Email does not work" ? See the troubleshooting below. TODO
This is just a quick guideline for easy setup of a development environment!
Make sure you have Apache, PHP 5.5+ and MySQL installed. Tutorial here. Nginx will work for sure too, but no install guidelines are available yet.
Edit vhost to make clean URLs possible and route all traffic to /public folder of your project:
sudo nano /etc/apache2/sites-available/000-default.confand make the file look like
<VirtualHost *:80>
DocumentRoot "/var/www/html/public"
<Directory "/var/www/html/public">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
Enable mod_rewrite and restart apache.
sudo a2enmod rewrite
service apache2 restartInstall curl (needed to use git), openssl (needed to clone from GitHub, as github is https only), PHP GD, the graphic lib (we create captchas and avatars), and 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 clone HUGE
sudo git clone https://github.com/panique/huge "/var/www/html"Install Composer
curl -s https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composerGo to project folder, load Composer packages (--dev is optional, you know the deal)
cd /var/www/html
composer install --devExecute the SQL statements. Via phpmyadmin or via the command line for example. 12345678 is the example password. Note that this is written without a space.
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"Make avatar folder writable (make sure it's the correct path!)
sudo chown -R www-data "/var/www/html/public/avatars"If this doesn't work for you, then you might try the hard way by setting alternatively
sudo chmod 0777 -R "/var/www/html/public/avatars"Remove Apache's default demo file
sudo rm "/var/www/html/index.html"Edit the application's config in application/config/config.development.php and put in your database credentials.
Last part (not needed for a first test): Set your SMTP credentials in the same file and set EMAIL_USE_SMTP to true, so you can send proper emails. It's highly recommended to use SMTP for mail sending! Native sending via PHP's mail() will not work in nearly every case (spam blocking). I use SMTP2GO.
Then check your server's IP / domain. Everything should work fine.
This is an untested NGINX setup. Please comment on the ticket if you see issues.
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;
}
}
Big thanks to razuro for this fine setup: Put this inside your root folder, but don't put any web.config in your public folder.
<?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>
Find the original ticket here.
By default there are two demo users, a normal user and an admin user. For more info on that please have a look on the user role part of the small documentation block inside this readme.
Normal user: Username is demo2, password is 12345678. The user is already activated.
Admin user (can delete and suspend other users): Username is demo, password is 12345678. The user is already activated.
There are several files in the root folder of the project that might be irritating:
- .htaccess (optionally) routes all traffic to /public/index.php! If you installed this project correctly, then this file is not necessary, but as lots of people have problems setting up the vhost correctly, .htaccess it still there to increase security, even on partly-broken-installations.
- .scrutinizer.yml (can be deleted): Configs for the external code quality analyzer Scrutinizer, just used here on GitHub, you don't need this for your project.
- .travis.yml (can be deleted): Same like above. Travis is an external service that creates installations of this repo after each code change to make sure everything runs fine. Also runs the unit tests. You don't need this inside your project.
- composer.json (important): You should know what this does. ;) This file says what external dependencies are used.
- travis-ci-apache (can be deleted): Config file for Travis, see above, so Travis knows how to setup the Apache.
README and CHANGELOG are self-explaining.
A real documentation is in the making. Until then, please have a look at the code and use your IDE's code completion features to get an idea how things work, it's quite obvious when you look at the controller files, the model files and how data is shown in the view files. A big sorry that there's no documentation yet, but time is rare and we are all doing this for free in our free time :)
- TODO: Full documentation
- TODO: Basic examples on how to do things
Currently there are two types of users: Normal users and admins. There are exactly the same, but...
-
Admin users can delete and suspend other users, they have an additional button "admin" in the navigation. Admin users have a value of
7inside the database table fielduser_account_type. They cannot upgrade or downgrade their accounts (as this wouldn't make sense). -
Normal users don't have admin features for sure. But they can upgrade and downgrade their accounts (try it out via /user/changeUserRole), which is basically a super-simple implementation of the basic-user / premium-user concept. Normal users have a value of
1or2inside the database table fielduser_account_type. By default all new registered users are normal users with user role 1 for sure.
See the "Testing with demo users" section of this readme for more info.
There's also a very interesting pull request adding user roles and user permissions, which is not integrated into the project as it's too advanced and complex. But, this might be exactly what you need, feel free to try.
To prevent CSRF attacks, HUGE does this in the most common way, by using a security token when the user submits critical forms. This means: When PHP renders a form for the user, the application puts a "random string" inside the form (as a hidden input field), generated via Csrf::makeToken() (application/core/Csrf.php), which also saves this token to the session. When the form is submitted, the application checks if the POST request contains exactly the form token that is inside the session.
This CSRF prevention feature is currently implemented on the login form process (see application/view/login/index.php) and user name change form process (see application/view/user/editUsername.php), most other forms are not security- critical and should stay as simple as possible.
So, to do this with a normal form, simply: At your form, before the submit button put:
<input type="hidden" name="csrf_token" value="<?= Csrf::makeToken(); ?>" />
Then, in the controller action validate the CSRF token submitted with the form by doing:
// check if csrf token is valid
if (!Csrf::isTokenValid()) {
LoginModel::logout();
Redirect::home();
exit();
}
A big thanks to OmarElGabry for implementing this!
In theory: Yes, but this feature didn't work in my tests. As it's an external feature please have a look into the according ticket for more.
- In 3.0 and 3.1 a user could log into the application from different devices / browsers / locations. This was intended behaviour as this is standard in most web applications these days. In 3.2 still feature is "missing" by default, a user will only be able to log in from one browser at the same time. This is a security improvement, but for sure not optimal for many developers. The plan is to implement a config switch that will allow / disallow logins from multiple browsers.
- Using this on a sub-domain ? You might get problems with the cookies in IE11. Fix this by replacing "/" with "./" of the cookie location COOKIE_PATH inside application/config/config.xxx.php! Check ticket #733 for more info. Thanks to jahbiuabft for figuring this out. Update: There's another ticket focusing on the same issue: ticket #681
There are some awesome features or feature ideas build by awesome people, but these features are too special-interest to go into the main version of HUGE, but have a look into these tickets if you are interested:
- Caching system
- ReCaptcha as captcha
- Internationalization feature
- Using controller A inside controller B
- HTML mails
- Deep user roles / user permission system
The idea of this project is and was to provide a super-simple barebone application with a full user authentication system inside that just works fine and stable. Due to the highly security-related nature of this script any changes mean a lot of work, lots of testing, catching edge cases etc., and in the end I spent 90% of the time testing and fixing new features or new features break existing stuff, and doing this is really not what anybody wants to do for free in the rare free-time :)
To keep the project stable, clean and maintainable, I would kindly announce the "soft-End of Life" for this project, meaning:
A. HUGE will not get any new features in the future, but ... B. bugfixes and corrections will be made, probably for years
While HUGE was in development, there were 3 main rules that helped me (and probably others) to write minimal, clean and working code. Might be useful for you too:
- Reduce features to the bare minimum.
- Don't implement features that are not needed by most users.
- Only build everything for the most common use case (like MySQL, not PostGre, NoSQL etc).
As noted in the intro of this README, there are also some powerful concepts that might help you when developing cool stuff: KISS, YAGNI, Feature Creep, Minimum viable product.
To avoid unnecessary work for all of us I would kindly recommend everybody to use HUGE for simple project that only need the features that already exist, and if you really need a RESTful architecture, migrations, routing, 2FA etc, then it's easier, cleaner and faster to simply use Laravel, Symfony or Zend.
However, here are the community-suggested possible features, taken from lots of tickets. Feel free to implement them into your forks of the project:
- OAuth2 implementation (let your users create accounts and login via 3rd party auth, like Facebook, Twitter, GitHub, etc). As this is a lot of work and would make the project much more complicated it might make sense to do this in a fork or totally skip it. (see Ticket #528)
- Router (map all URLs to according controller-methods inside one file), Ticket 727
- RESTful architecture (see ticket #488 for discussion)
- Horizontal MySQL scaling (see ticket #423 for discussion)
- Modules / middleware
- Logging
- Two-Factor-Authentication (see ticket #732)
- Controller-less URLs (see ticket #704)
- Email-re-validation after email change (see ticket #705)
- Connect to multiple databases (see ticket #702)
- A deeper user role system (see ticket #701, pull-request #691), ticket #603
- How to run without using Composer ticket #826
There were two (!) support forums for v1 and v2 of this project (HUGE is v3), and both were vandalized by people who didn't even read the readme and / or the install guidelines. Most asked question was "script does not work plz help" without giving any useful information (like code or server setup or even the version used). While I'm writing these lines somebody just asked via Twitter "how to install without Composer". You know what I mean :) - 99% of the questions were not necessary if the people would had read the guidelines, do a minimal research on their own or would stop making things so unnecessarily complicated. And even when writing detailed answers most of them still messed it up, resulting in rants and complaints (for free support for a free software!). It was just frustrating to deal with this every day, especially when people take it for totally granted that it's the duty of open-source developers to give detailed, free and personal support for every "plz help"-request.
So I decided to completely stop any free support. For serious questions about real problems inside the script please use the GitHub issues feature.
Harsh words, but as basically every public internet project gets harassed, vandalized and trolled these days by very strange people it's necessary: Some simple rules.
-
Respect that this is just a simple script written by unpaid volunteers in their free-time. This is NOT business-software you've bought for $10.000. There's no reason to complain (!) about free open-source software. The attitude against free software is really frustrating these days, people take everything for granted without realizing the work behind it, and the fact that they get serious software totally for free, saving thousands of dollars. If you don't like it, then don't use it. If you want a feature, try to take part in the process, maybe even build it by yourself and add it to the project! Be nice and respectful. Constructive criticism is for sure always welcome!
-
Don't bash, don't hate, don't spam, don't vandalize. Please don't ask for personal free support, don't ask if somebody could do your work for you. Before you ask something, make sure you've read the README, followed every tutorial, double-checked the code and tried to solve the problem by yourself.
Trolls and very annoying people will get a permanent ban / block. GitHub has a very powerful anti-abuse team.
Please commit only in develop branch. The master branch will always contain the stable version.
Scrutinizer (master branch), Scrutinizer (develop branch), Code Climate, Codacy, SensioLabs Insight.
Due to the possible consequences when publishing a bug on a public open-source project I'd kindly ask you to send really big bugs to my email address, not posting this here. If the bug is not interesting for attackers: Feel free to create an normal GitHub issue.
See active issues here: https://github.com/panique/huge/issues?state=open
Interesting issue: When a user hits your website, the user's browser will also request one or more (!) favicons (different sizes). If these static files don't exist, your application will start to generate a 404 response and a 404 page for each file. This wastes a lot of server power and is also useless, therefore make sure you always have favicons or handle this from Apache/nginx level.
HUGE tries to handle this by sending an empty image in the head of the view/_templates/header.php !
More inside this ticket: Return proper 404 for missing favicon.ico, missing images etc.
More here on Stackflow: How to prevent favicon.ico requests?, Isn't it silly that a tiny favicon requires yet another HTTP request? How to make favicon go into a sprite?.
- How long will my session last?
- How to do expire a PHP session after X minutes?
- How to use PDO
- A short guideline on how to use the PHP 5.5 password hashing functions and its PHP 5.3 & 5.4 implementations
- How to setup latest version of PHP 5.5 on Ubuntu 12.04 LTS
- How to setup latest version of PHP 5.5 on Debian Wheezy 7.0/7.1 (and how to fix the GPG key error)
- Notes on password & hashing salting in upcoming PHP versions (PHP 5.5.x & 5.6 etc.)
- Some basic "benchmarks" of all PHP hash/salt algorithms
- How to prevent PHP sessions being shared between different apache vhosts / different applications
- interesting article about password resets (by Troy Hunt, security expert)
- Password-Free Email Logins: Ticket & discussion, article
- Logging in via QR code: Ticket & discussion, english article, german article, repo, live-demo. Big thanks to PHPGangsta for writing this!
I'm also blogging at Dev Metal.