Jump to content
bfarber
 Share


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.

 Share

Comments

Recommended Comments

Great to know that it is now possible to import more data from external databases - I need that feature often.

I have a question regarding chaining methods together - am I right to assume that you could say, for example have the internal authentication as the primary module, and open id as a secondary creating a situation where people with an open id could sign in using that, but people who don't could register and log in with the internal system as normal?

Link to comment
Share on other sites

[quote name='Professor P' date='May 23 2008, 06:42 PM']Great to know that it is now possible to import more data from external databases - I need that feature often.

I have a question regarding chaining methods together - am I right to assume that you could say, for example have the internal authentication as the primary module, and open id as a secondary creating a situation where people with an open id could sign in using that, but people who don't could register and log in with the internal system as normal?

Yup, exactly. :) On the login form you would see

"Signin Name _____________
Password ______________
Or use OpenID ______________"

Just fill in whatever makes you happy :lol: In fact, in my testing I had Internal, Converge and OpenID all enabled. Though I don't suspect that would be a common instance, it all worked flawlessly. Things can start to get a little tricky once you have some that use email and some that use username, and when you start appending remote logout url callbacks and so on, but the login handler has been updated a little to support actual logout callbacks, so you don't have to fill in the URL to send someone to when they click logout. All in all, it's a much more robust system now that should be flexible enough to account for just about any login situation.

Link to comment
Share on other sites

Glad to see that the login method fits for different business evironments with IPB 3.0. I hope, once 3.0 is out, it will be easy to convert or merge the users to the different databases.

I am looking forward to see it :)

Link to comment
Share on other sites

Brandon, looks nice, but with 2.X if you use an external database, at first login the users emailaddress is taken and stored in the ipb database, when a user now changes his emailaddres, it is only changed in the external database and the ipb info is out of sync. Is there some smart thing in 3.x for that?
And to login in joomla >1.0.13, I had to change some code in the auth.php from ipb, to use the salted password scheme there, I can supply code that works for that, Would be nice if integrated standard.

Link to comment
Share on other sites



Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...