Jump to content

Advancing the Login Manager

IP.Board 2 included a login manager utility in the admin control panel. Using this tool, you could tell IP.Board to authenticate login requests against third party databases, LDAP installations, or against IP.Converge, for example. You could even write up your own login methods and authenticate against any external data source of your choosing (i.e. the IP.Board 2.3 OpenID module). We used the login manager for conversions too - if you converted from another forum software, our login manager can understand the old password hashing schemes so that you do not need to reset all of your users' passwords (in most cases).

IP.Board 3 takes the login manager even further.

The login forms on the front end are all being consolidated into one template. This will make it easier to ensure that every time a login form is displayed, the same login form is displayed. You won't have to add options to multiple templates, as you did in IP.Board 2, if you want to customize the login form in any way. The login form has also been made "smart". Because you could potentially have a login method that requires a username and a login method that requires an email address, we decided to dumb down the form a little bit. You will be asked for your "sign in name" now (just one field) and IP.Board will figure out if you submitted an email address or a username.

We've removed the option of "passthrough" or "onfail" from the login manager. It is no longer needed, as you can now chain login methods together. For instance, you may want to try to authenticate a user against the local database first (if the account exists), but if that fails, load the member from a remote database. Or you may want to allow a user to login using one of a number of data sources you maintain. This functionality is now possible. The login methods in the admin control panel are reordered using drag-n-drop to make it easy to control which order they are checked in.

Some login methods need extra information from you. For instance, if you use LDAP, IP.Board would need to know the LDAP server host name, your username and password to login to LDAP to check the user, and so on. In IP.Board 2, this information is entered into a configuration PHP file. IP.Board 3 presents this information in the admin control panel to make it easier for you to check and update whenever you may need to.

In IP.Board 2 when a member is added to the local database after authenticating through a remote data source, the member would be required to fill in a display name, and potentially their email address, even if that information already existed in the remote source. In IP.Board 3, there is much more control over this at the login method level - you can pull ANY data you want from a remote source and use it in IP.Board. At the very least, this means if there is an email address and a username available in your remote data source, the user most likely will not be required to visit an intermediary screen before being allowed access to your forums. The name and email will be stored automatically, making for a very seamless login experience.

IP.Converge has received a slight update too - if you have IP.Converge enabled on your board, your users (who have already logged into the forum and configured their account) will now be able to use their username to login (if you enable username logins in the ACP). Behind the scenes IP.Board will find their email address and authenticate through IP.Converge using their email address, but your users won't have to know that.

Additionally, OpenID has being added to IP.Board 3 as a supported login method. If you are not familiar with OpenID, it is basically an emerging protocol allowing you to control your own login authentication. You submit a url to sites that support OpenID (such as Yahoo, Wordpress, Flickr, and AOL) and then you are taken to that URL to verify the request really is from you. You may be required to login to your OpenID provider to confirm what information you are allowing to be sent back to the requester (in this case, your forums). After you confirm this information, you will be automatically logged into your forum. Additionally, as long as the user allows their name and email address to be sent back to the forums, their account will be fully created and functional. IP.Board will support OpenID 1 and OpenID 2 with the Simple Registration, Attribute Exchange, and PAPE extension modules (meaning email, username, date of birth and gender will all be supported and remembered by IP.Board, and that you can supply a policy url to the OpenID provider). Please note that we will be using the PHP OpenID libraries from JanRain for the OpenID backend support.

If you don't need any of this functionality, it won't impact you at all! For those of you who have been requesting it, however, IP.Board 3 should cover all your bases.

  • Create New...