After you’ve installed and configured Community Auth, you’ll want to customize your application to use it, and creating a login form is essential. You’ll need to make some decisions and do a little configuration.
Most (if not all) websites will have a link or button that allows a logged in user to log out, and Community Auth makes logging out very easy.
User profile tables allow you to have unique data that is tied to your users, while acknowledging that not all users are the same. For instance, you may need to store different types of data for a customer versus an admin, or one type of employee versus another. By default Community Auth no longer integrates profile tables, but setting them up is simple, as you can see by the rather short length of this blog post.
The goal of this blog post is to show you how to retrieve profile data and add it to the other authentication variables that Community Auth makes available.
Especially if you are using database sessions with CodeIgniter, you should be aware that if you call a stored procedure, any query after the call with give you the Commands Out of Sync error:
Error Number: 2014
Commands out of sync; you can’t run this command now
— The query after your procedure call —
Line Number: 247
Community Auth currently provides some shell scripts that help you get up and running quickly. None of these scripts are required for the install process, and they’ll only work for Linux and Mac users. There are some assumptions made in regards to running these scripts, and you know what they say about assumptions.
- They will be made executable using chmod.
- The script will be in the proper location before you execute it.
- Bash is located at /bin/bash.
A new feature was added to Community Auth on January 7th, 2016. This new feature, a post auth hook, is an empty method that is called after an authentication method is called in one of your controllers.
Technically it’s not really a timestamp, but a MySQL datetime field in the users table, and there are some interesting things you can do with this field.
On January 9, 2016 a new field was added to the users table, called “passwd_modified_at”, and code to set up a MySQL trigger was introduced at the same time. The trigger is handy, because it will update the passwd_modified_at field any time a user’s password is changed. This means you don’t have to worry about updating this field, and can simply benefit from it existing.
Community Auth has had a feature for some time that locks a person from attempting to login if they exceed a defined amount of login attempts. When that person waits 10 minutes, or however long you configure the waiting time, the person can then attempt to login once again. This works great, but if somebody bypasses the form and attempts to login via a script, Community Auth will at some point attempt to deny access to the IP address where those requests are coming from.
This feature may or may not be all that useful, but as it was before v3.1.0, a bug in the regular expression (regex) that rebuilds the deny list could render a site completely unusable. The condition leading to such a case would be brought about by an .htaccess file that is of medium to large filesize.
It’s important that you know how to use Community Auth’s authentication methods, and due to feedback in the CodeIgniter forum, it’s clear that some developers are calling authentication methods more than once per request.
You don’t want to call more than one authentication method per request, because everything you need for authentication is done in the first request.
There are a few opinions on how or how not to validate passwords, and it’s a complicated subject. Most website owners are going to want to ensure that people aren’t using weak passwords, and many website users are going to think it’s a great annoyance to be forced to come up with a password that meets a website’s expectations.