Bridge

[najaru]

ho trovato questo, può essere di aiuto?

If you are integrating with IP.Board and need to authenticate a user login, you should require the appropriate IP.Board files to do this.

Here is a sample class that can accomplish this:
[code]<?php
class ipbAuthentication
{
	/**
	 * initialisation function to setup IPSregistry
	 */
	protected function init()
	{
		/**
		 * Edit this path, to where you have your forum installed.
		 */
		$forum_path = '/path/to/forum';

		/**
		* We will change directories so that proper directory is picked up
		*/
		chdir( $forum_path );

		/**
		* Get some basic IPB files
		*/
		define( 'IPB_THIS_SCRIPT', 'public' );
		require_once( $forum_path . '/initdata.php' );

		/**
		* Get IPB registry
		*/
		require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );
		require_once( IPS_ROOT_PATH . 'sources/base/ipsController.php' );

		/**
		 * initialise the ipsRegistry
		 */
		$this->ipbRegistry	= ipsRegistry::instance();
		$this->ipbRegistry->init();
	}
	/**
	 * logs a user in, username and password should be in $_REQUEST['username'] and $_REQUEST['password']
	 */
	public function doLogin()
	{
		/**
		 * call the initialisation function
		 */
		$this->init();

		/**
		 * get the IPB login handler wrapper
		 */
		require_once( IPS_ROOT_PATH . 'sources/handlers/han_login.php' );

		/**
		 * setup the handler class
		 */
		$login = new han_login( $this->ipbRegistry );
		$login->init();

		/**
		 * verify the login and do any necessary tasks. form variables must be called 'username' & 'password'
		 */
		$login->verifyLogin();

		if($login->return_code == 'SUCCESS')
		{
			/**
			 * login was successful
			 */
			echo 'Login Successful';
		}
		else
		{
			/**
			 * login failed, error code stored in $login->return_code;
			 */
			echo 'There was a problem logging in, Error Code: ' . $login->return_code;
		}
	}
	/**
	 * logs the current user out and converts them to a guest
	 */
	public function doLogout()
	{
		/**
		 * call the initialisation function
		 */
		$this->init();

		/**
		 * clear the users cookies
		 */
		IPSCookie::set("member_id", 0, 0, -5);
		IPSCookie::set("pass_hash", 0, 0, -5);

		/**
		 * change the users session into a guests session
		 */
		$this->ipbRegistry->member()->sessionClass()->convertMemberToGuest();

		echo 'You are logged out';
	}
}
?>

To make the above class function you will need the following code. If you don't place this in the same file as the above class, you will need to include(); the file containing the class.

<?php
/**
 * initiate ipb functions
 */
$ipblink = new ipbAuthentication;

 /**
 * logging a user in
 */
if(isset($_REQUEST['username']) && isset($_REQUEST['password']))
{
	$ipblink->doLogin();
}
else
{
	echo 'You did not supply all the required credentials';
}

/**
* log current user out
*/
$ipblink->doLogout();
?>

By using the login handler, all of the available login methods will be cycled through and the user checked appropriately. Additionally, brute force account locking and proper cleaning of parameters will be done so that you can ensure the parameter values will match accordingly. You must be sure that the data is encoded in the same character set as your forums are encoded with. For instance, if your site is iso-8859-1 and your forums are utf-8 encoded, any special characters cannot be matched properly and the login will fail.

[svacant]

Prova ad aggiornare il cms col file utils.class.php (dentro la dir framework) e poi login_ipb estrailo dentro plugins.

Una volta attivato potrai inserire la path del forum nel pannello admin (cliccando su login_ipb).

Non ti assicuro che funzioni.

login_ipb.zip

utils.class.php

[najaru]

stiamo parlando di cose da fare dentro MyFrame, giusto?

[svacant]

stiamo parlando di cose da fare dentro MyFrame, giusto?

Sì ovvio, ho implementato la classe che hai postato, però non so se funziona non ho un forum ipb.

[najaru]

ho fatto quello che hai detto, attivato il plugin nell'admin. ma poi non ho capito dove devo veder spuntare qualcosa, e dove inserire i dati del mio forum

[svacant]

Una domanda ma questa classe per che versione di ipb è?

[najaru]

in teoria della 3.

comunque ora ti metto tutte le info che c'è in resource per il login

Introduction

There is built in support within our session handler for your own session handling events. You may want to log a user in automatically based on your own authentication, for example or you may just want to synchronize session location and update times.

We have added call-outs at specific points during the session loading and authentication process to enable you to 'hook' into session management.

Requirements

You'll need to create a brand new file at this location: ./admin/sources/classes/session/sso.php

A bare bones class will look like this:

class ssoSessionExtension

{

/**

* Constructor

*

* @access public

* @param object ipsRegistry object

*/

public function __construct( ipsRegistry $registry )

{

}

/**

* CheckSSOForGuest

* Used when IP.Board session auth validates user as a guest

*

* @access public

* @param string $type Either: 'update' (Session is being up-dated) or 'create' (Session is being created)

*/

public function checkSSOForGuest( $type='create' )

{

}

/**

* checkSSOForMember

* Used when IP.Board session auth validates user as a member

*

* @access public

* @param string $type Either: 'update' (Session is being up-dated) or 'create' (Session is being created)

*/

public function checkSSOForMember( $type='create' )

{

}

}

IP.Board from 3.0.4 onwards contains a file called ./admin/sources/classes/session/sso.rename.php that can be renamed and used as a basis for your own code.

The __construct magic method accepts a single variable $registry which contains the ipsRegistry object. You can use the standard IP.Board constructor code here to set up class variables that you will be familiar with:

/* Make object */

$this->registry = $registry;

$this->DB = $this->registry->DB();

$this->settings =& $this->registry->fetchSettings();

$this->request =& $this->registry->fetchRequest();

$this->cache = $this->registry->cache();

$this->caches =& $this->registry->cache()->fetchCaches();

$this->_member = self::instance();

$this->_memberData =& self::instance()->fetchMemberData();

The member ipsRegistry object is not fully initialized when the SSO classes are called. If you do need to create a member via IPSMember::create() then pass a third parameter as TRUE to prevent some code from executing which will prevent IP.Board from exiting with a fatal error, like so: IPSMember::create( $memberData, TRUE, TRUE );

The other two functions: checkSSOForGuest and checkSSOForMember accept a single parameter $type which informs your SSO class that our session handler has either created or updated a session should that make a difference to your own code.

You are responsible for accessing your own cookies or $_SESSION variables to authenticate the user against your own system.

You could, for example, decide to log the user into your own system when checkSSOForMember has been called, or create the user in the IP.Board database and log them in when checkSSOForGuest is called.

Advanced developers can make use of the ability to fully extend the default session handling classes by adding files named ssoPublicSessions.php and ssoAdminSessions.php. You can override any default session class method with these classes.

Introduction

IP.Board supports custom login modules for member authentication. An external database, with the desired member base, can be used for authenticating users for IP.Board. IP.Board comes standard with the following login authentication methods:

External Database

Used for authenticating via an external database. The default external authentication method that is included with the IP.Board download is based on a phpBB database.

IP.Converge

The method is used to authenticate users via a IP.Converge service. This allows multiple Invision Power applications to use the same accounts for each application.

IP.Board Internal

The standard method of authentication for IP.Board

LDAP Authentication

LDAP / Active Directory Authentication

Open ID

Open ID Authentication

Windows Live

Used for Windows Live authentication. You must register with Microsoft before using this log in method.

Creating a Custom Login Method

This section will provide a basic tutorial in order to create a custom login method adapted from the external login method issued with IP.Board. Upon completing a custom login method, the login method will allow IP.Board to authenticate users via an external database to IP.Board. This method will be called by the IP.Board login_core when there is a need to authenticate a username/password, depending on the login method setup. For the purposes of this tutorial, we'll call the log in method "Test" that has a folder name of ./admin/sources/loginauth/test

Configuration Setup

There are several files used for login methods, auth.php, acp.php, loginauth_install.xml and conf.php; they are all located in the folder ./admin/sources/loginauth/test. The file, conf.php, is the configuration file. It can contain multiple variables regarding the configuration of this login method. These variables' values could be used as parameters to connect to the remote MySQL database, for example. You can use the acp.php file to show the conf.php variables in the Admin CP. conf.php must be world writeable so that the Admin CP can write the data back to it. This is optional and acp.php is not required.

Developing Authorization Type

This is our example auth.php file for our test log in method. The class name must be called login_{folder name here}. This class is an extension of the login_core that implements interface_login.

class login_test extends login_core implements interface_login

{

/**

* Properties passed from database entry for this method

* @access protected

* @param array

* /

protected $method_config = array();

/**

* Properties passed from conf.php for this method

* @access protected

* @param array

* /

protected $external_conf = array();

/**

* Constructor

* @access public

* @param object ipsRegistry object

* @param array DB entry array

* @param array conf.php array

public function __construct( ipsRegistry $registry, $method, $conf=array() )

{

$this->method_config = $method;

$this->external_conf = $conf;

parent::__construct( $registry );

}

/**

* Authenticate the member against your own system

* @access public

* @param string Username

* @param string Email Address

* @param string Plain text password entered from log in form

public function authenticate( $username, $email_address, $password )

{

/* Depending on your type of auth, username or email address will be blank

For this example, we’ll only accept email address log in and this will

be set from the Admin CP.*/

/* We assume that myDB is a static class that interfaces with your own

database systems */

$member = myDB::query(“select id, userName, emailAddress from myMembers where emailAddress=’$email_address’”);

if ( ! $member[‘id’] )

{

$this->return_code = ‘NO_USER’;

return false;

}

if ( md5( $password ) != $member[‘md5Password’] )

{

$this->return_code = ‘WRONG_AUTH’;

return false;

}

if ( $member[‘id’] )

{

$this->return_code = ‘SUCCESS’;

/* We must populate $this->member_data if we find a matching user

if we do not have one, one must be created like so */

/* Test locally */

$localMember = IPSMember::load( $member[‘emailAddress’] );

if ( $localMember[‘member_id’] )

{

$this->member_data = $localMember;

}

else

{

$this->member_data = $this->createLocalMember( array( 'members' => array( 'name' => $member[‘userName’],

'password' => $password, ‘email’ => $mem-ber[‘emailAddress’] ) ) );

}

return true;

}

}

}

The authenticate function will be called with the username, email address and password parameters. Depending on the value of 'Log in Type' either $email_address or $username will be blank. You can make any necessary changes to this function to handle your needs, but you will need to make sure the function loads authenticated members and returns one of these set return codes.

There are four return codes and they are as follows:

• 'ERROR': There was an error, check the array: $class->auth_errors
• 'NO_USER': There was no user found in IP.Board record set, but authentication passed in REMOTE directory
• 'WRONG_AUTH': Authentication failed, wrong password or username
• 'SUCCESS': Successful authentication, user and password matched. Load member if they exist or create new member for IP.Board.

As outlined in our test class, upon each passed authentication, there will be two scenarios. One, the user will exist within the remote database, but has yet to register a member account for the IP.Board installation. If this is the case, in the authentication function you will need to either make a call to the IP.Board member creation function passing an array of member data: like array( 'members' => array( 'name' => $name, 'members_display_name' => $name, 'password' => $password, 'email' => $email ). This is the very basic data required. You can send more data by setting the key to a members table field name.
The second scenario would be, the user passes authentication and has an existing IP.Board membership. Before exiting the authorization script, the member needs to be loaded.
Finally, an XML file is required so that the log in module can be installed via the Admin CP.
Here is the XML file for our example. It would be located at: admin/sources/loginauth/test/loginauth_install.xml
<?xml version="1.0" encoding="iso-8859-1"?>
<export exported="1210273051">
<group>
<row>
<login_title>Test Auth Module</login_title>
<login_description>Just our test</login_description>
<login_folder_name>test</login_folder_name>
<login_maintain_url></login_maintain_url>
<login_register_url></login_register_url>
<login_alt_login_html></login_alt_login_html>
<login_settings>1</login_settings>
<login_enabled>0</login_enabled>
<login_safemode>1</login_safemode>
<login_replace_form>0</login_replace_form>
<login_user_id>email</login_user_id>
<login_login_url></login_login_url>
<login_logout_url></login_logout_url>
</row>
</group>
</export>
The only items you must ensure you enter correctly is login_title, login_description, login_folder_name and login_user_id. login_user_id must be set to 'email' for email authentication or 'username' for user name authentication. The other settings can be edited via the Admin CP.
Configuring the LDAP Login Method
To set Invision Power Board to authenticate against LDAP, there are a couple of steps that must be taken. Firstly, you must ensure that PHP has been compiled with LDAP support, as IP.Board utilizes these functions. In the ACP, go to your Admin tab, click on "PHPINFO", and in the "Configure Command" section at the top of the phpinfo output, verify that you see "--with-ldap". If not, you will need to recompile PHP with LDAP support, which is beyond the scope of our support capabilities. More information can be found here on the PHP LDAP libraries and how to enable them.
If PHP has been compiled with LDAP support, download the ./sources/loginauth/ldap/conf.php file from your web server and configure the directives. If you are unsure of the settings to place in this file, you should contact your LDAP Admin to find out what settings will work best.
A user using Win2K3 Active Directory has indicated the following settings should be used to authenticate against your AD. You will, of course, need to make the appropriate changes, but note username information will require 2 slashes.
<?php
// LDAP -- LDAP
$LOGIN_CONF = array();
$LOGIN_CONF['ldap_server'] = 'xxx.xxx.xxx.xxx'; //- IP Address of LDAP
Server
$LOGIN_CONF['ldap_port'] = '389';
$LOGIN_CONF['ldap_server_username'] = 'domain\\user'; //- make sure
you have the two
$LOGIN_CONF['ldap_server_password'] = 'password';
$LOGIN_CONF['ldap_uid_field'] = 'sAMAccountName';
$LOGIN_CONF['ldap_base_dn'] = 'dc=domain,dc=com'; //- if your
domain name is "domain.com"
$LOGIN_CONF['ldap_server_version'] = 3;
$LOGIN_CONF['ldap_username_suffix'] = '';
$LOGIN_CONF['ldap_user_requires_pass'] = 1;
$LOGIN_CONF['ldap_opt_referrals'] = 0;
?>
For a full and up-to-date list of configuration settings, please open ./admin/sources/loginauth/ldap/conf.php in a text editor. Each configuration is well commented.
Afterwards, upload the (modified) file back to your server in the same folder (./admin/sources/loginauth/ldap/) and login to your IP.Board ACP. Visit "Tools & Settings", and click on "Login Manager" in the left hand menu. Click on the button for the LDAP Authentication row, and click "Edit Details".
You will need to ensure that your remote code updates the IP.Board user's email address and password if the user changes them within your system. If you do not, they will be disassociated with the IP.Board member account.
Set "Log In Enabled" to "Yes" to enable this module.
IP.Board will still allow you to login to the ACP with your local member account - in fact IP.Board will only check the local database for ACP access. However, you should now be able to login to the board with a user account that can be found in your LDAP directory. If you are successful, you will be asked to fill in some vital information on your first login, and subsequent logins will merely authenticate against the remote database (you will not be asked for your display name again, for example).
If you configure the above settings and are unable to login to the board with a user account you know to be active in your LDAP directory, please submit a ticket and one of our technicians will be able to assist you further.
Configuring the OpenID Method
The openID method doesn't require any modification by default. If you open admin/sources/loginauth/openid/conf.php you can see the configuration values. The most important configuration is the directory that will contain the OpenID temporary files.
$LOGIN_CONF['store_path'] = DOC_IPS_ROOT_PATH . 'cache/openid';
Just make sure that directory is writeable by PHP before enabling this log in method.
Configuring the Windows Live Method
To set Invision Power Board to authenticate with Windows Live there are a few steps that must be taken.
Firstly, you will need to register your site as an application and receive an application ID to make use of Windows Live Services. See http://msdn.microsof...y/bb676626.aspx for more information on how to register your site. When you register and are asked for the Return URL, you must use http://(yourdomain.com)/(path to forums)/interface/board/live.php. Of course, replace "(yourdomain.com)" with your domain name, and "(forums)" with the path to your forums. An example may be: http://www.mattmecham.com/forums/interface/board/live.php
Afterwards registering your site, you will be presented with some necessary information. You will need to keep a note of the application ID and the secret key.
Open /admin/sources/loginauth/live/Application-Key.xml and edit the "appid" and "secret" XML keys to the appropriate values supplied when you registered your site. Then take this file and upload it to your server.
<windowslivelogin>
<appid>00167FFE80002700</appid>
<secret>ApplicationKey123</secret>
<securityalgorithm>wsignin1.0</securityalgorithm>
</windowslivelogin>
The default location can be changed and it is recommended that you do so for the best security. To do this, simply move the Application-Key.xml file to another location on your server. For example, if you had a standard linux Hosting account, your path to your forums may be: /home/mattmecham/public_html/forums/. In this case, we'd recommend storing the XML file in /home/mattmecham/Application-Key.xml. You'd then open up /admin/sources/loginauth/live/conf.php and update the location like so:
$LOGIN_CONF['key_file_location'] = '/home/mattmecham/Application-Key.xml';

Located in ./admin/sources/base/core.php is a static class called IPSMember. This class holds many useful utility functions. The most useful are:
Create
Usage: $new_member = IPSMember::create($data, TRUE );
This function will take an array of data and create a new member completing all the required SQL tables and fields and will return the member data including 'member_id'.
The first parameter, $data must be an array in the format of array( tableName => arrayOfData), an example would be:
$new_member = IPSMember::create(
array( ‘members’ => array( ‘name‘ => ‘BobSmith’,
‘email‘ => ‘bsmith@email.com’,
‘password’ => ‘myPassword’ ) ), TRUE );
You can use friendly aliases in the place of table names.
'core' is an alias of 'members'
'extendedProfile' is an alias of 'profile_portal',
'customFields' is an alias of 'pfields_content'
You can pass a plain text password via table field key 'password' as shown in the above example. If one is not supplied, IP.Board will auto generate a password for the new user. You must, however, ensure that the plain text password has been sanitized either via IPSText::parseCleanValue($password ) or via a function similar to one below.
function sanitizePassword( $password )
{
$password = str_replace( array( "\r\n", "\n\r", "\r" ), "\n", $password );
$password = str_replace( "&" , "&" , $password );
$password = str_replace( "<!--" , "<!--" , $password );
$password = str_replace( "-->" , "-->" , $password );
$password = str_ireplace( "<script" , "<script" , $password );
$password = str_replace( ">" , ">" , $password );
$password = str_replace( "<" , "<" , $password );
$password = str_replace( '"' , """ , $password );
$password = str_replace( "\n" , "<br />" , $password );
$password = str_replace( "$" , "$" , $password );
$password = str_replace( "!" , "!" , $password );
$password = str_replace( "'" , "'" , $password );
}
You can pass any data through you wish. You may wish to pass more information, like:
$new_member = IPSMember::create(
array( ‘members’ => array( ‘name‘ => ‘BobSmith’,
‘email‘ => ‘bsmith@email.com’,
‘members_display_name’ => ‘Bob Smith’,
‘restrict_posts‘ => 1 ) ), TRUE );
The second parameter (TRUE in our examples) is a boolean flag to denote whether to auto create a user name and display name in the event they are taken. It does this by counting how many members there are with name and adding '_x' at the end. So, if there were four members with the name 'BobSmith', it would create 'BobSmith_5'.
Passing FALSE will simply leave the name and display name empty.
If a name, display name or email address is not passed then it will add a record in the 'members_partial' table. This will mean that when the user attempts to log in they will be prompted to enter a valid name, display name and/or email address.
A third boolean parameter can be used to prevent extra code from executing (custom profile fields, etc) during member creation. This is used when you are writing code within the session classes as the ipsRegistry member object would not be fully initialized at this point.
Load
Usage: $member = IPSMember::load($memberId, 'core,extendedProfile' );
This will function will accept either an integer for a single member, or an email address of a single member or array of integers as $memberId. The second parameter allows you to specify which tables are loaded. You can omit the second parameter completely and it will default to 'all' which loads all tables. If you pass an integer as $memberId then the function will return an array of data. If you passed an array, it will returned an array indexed by member IDs, like so: array( memberId => data ).
An example:
$member = IPSMember::load( 1, ‘all’ );
print $member[‘member_id’];
$members = IPSMember::load( array( 1,2,3,4), ‘all’ );
foreach( $members as $memberId => $memberData )
{
print $memberData[‘name’];
}
Save
Usage: IPSMember::Save( $memberId, $data);
This function will accept an integer as a member ID or a string as an email address. The second parameter will contain an array in the same format as used in IPSMember::create,that is an array in the format of array(tableName => arrayOfData).
This function will trigger any relevant memberSync operations.
An example:
IPSMember::save( 1, array( ‘core’ => array( ‘restrict_posts’ => 0 ) ) );

Introduction
This section of the document contains general information about member handling within IP.Board.
The following tables are used when storing and managing members. Relevant fields are listed. There may be more fields but in most cases they are used internally.
Table: member
field Information Type member_id Primary ID. This is set to automatically increment INT(8) name Log in name VARCHAR(255) member_group_id Primary group id INT(3) mgroup_others Comma delisted string of other group ids VARCHAR(255) email Email address VARCHAR(150) joined Unix timestamp of date joined INT(10) ip_address IP address of when the user registered VARCHAR(16) title Title (can be assigned manually or via ranks) VARCHAR(64) language Language ID (prior to 3.0, was string, now INT) VARCHAR(32) view_sigs Flag to denote if user wishes to view signatures INT(1) view_img Flag to denote if user wishes to view posted images INT(1) view_avs Flag to denote if user wishes to view avatars INT(1) bday_day Birthday Day INT(2) bday_month Birthday Month INT(2) bday_year Birthday Year INT(4) last_visit Unix timestamp of last visit (prior to current session) INT(10) last_activity Unix timestamp of last activity (session click) INT(10) dst_in_use Flag to denote if user is observing Daylight savings INT(1) coppa_user Flag to denote if user was registered under COPPA INT(1) mod_posts Flag to denote if user has posts on moderator preview INT(1) temp_ban String containing any temporary ban information VARCHAR(50) sub_end Unix timestamp of purchased subscription expiration INT(10) org_perm_id Comma delisted string of overridden permission masks VARCHAR(255) member_login_key MD5 hash of log in key used in cookie for auto log in VARCHAR(32) member_login_key_expire Unix timestamp of when log in key is set to expire INT(10) members_display_name Display Name VARCHAR(255) members_seo_name Display Name in SEO format (built automatically) VARCHAR(255) members_created_remote Flag to denote if user was created remotely INT(1) members_l_display_name Lowercase version of display name for indexing VARCHAR(255) members_l_username Lowercase version of log in name VARCHAR(255) failed_logins String of failed log in data (handled internally) TEXT failed_login_count Number of failed log ins INT(3) members_pass_hash MD5 hash of salted plain text password VARCHAR(32) members_pass_salt Password salt used when hashing for security VARCHAR(5) identity_url OpenID URL VARCHAR(255) member_banned Flag to denote if user is permanently banned INT(1)
Table: profile_portal
FIELD INFORMATION TYPE pp_member_id Must be same as members.member_id INT(10) pp_profile_update Unix timestamp of last profile data update INT(10) pp_main_photo File name of the uploaded folder (into /uploads) VARCHAR(255) pp_main_width Pixel width of uploaded photo INT(5) pp_main_height Pixel height of uploaded photo INT(5) pp_thumb_photo Generated thumbnail file name VARCHAR(255) pp_thumb_width Pixel width of photo thumbnail INT(5) pp_thumb_height Pixel height of photo thumbnail INT(5) pp_profile_views Number of profile views INT(5) pp_about_me About me text as entered by the user TEXT signature Signature added to each post made TEXT avatar_location Location of avatar (will change based on type) VARCHAR(255) avatar_size Size of avatar (string, wxh) VARCHAR(9) avatar_type Type of avatar (upload, url, etc) VARCHAR(15) fb_photo Facebook linked photo location TEXT fb_photo_thumb Facebook linked photo thumbnail location TEXT fb_bwoptions Bitwise options for Facebook INT(10) pp_status Status for user as entered by user Òis writing docsÓ TEXT pp_status_update Unix timestamp of status update VARCHAR(13)
There are several other tables that relate to members but they are managed internally and you should never need to edit the information in them manually. Records are created on-the-fly if they do not exist.
Generally speaking, if you stick to the functions listed in this document you will not need to directly edit a database table.

IP.Board features abstracted login authentication management, allowing for users to add login modules to change how IP.Board authenticates users during the process. Using this, IP.Board includes LDAP, Converge, and OpenID support, for instance. The login module system is expandable so that you can create (and share) your own login modules if needed.
To create a login module you will need to first create a couple of files on disk. The location of the login modules is admin/sources/loginauth/. Create a folder for your new login module, and then within the folder you will want to create a file called auth.php. We will come back to this file in a moment.
We should note here that your login module can also support two additional files within your folder: conf.php and acp.php.
conf.php
This file is a configuration file that can be used in the event that configuration of the module is required. For instance, with Converge there is no custom configuration required, however with OpenID you can define which pieces of information to retrieve from the OpenID server, the policy URL, and the file system path to use for temporary files. The conf.php provides an abstracted configuration system to support this.
The file should contain an array $LOGIN_CONF with simple key => value pairings. Do not make the array multidimensional if you can avoid it. See an example conf.php from the LDAP or OpenID login modules for an example.
This file should be CHMOD 777 if you plan to allow the admin to configure the module from the ACP.
acp.php
This file is a configuration file that allows you to define the fields needed to configure conf.php so that an administrator can configure your module from the ACP, rather than having to edit the file directly. It is obviously not required if you have no conf.php.
The acp.php file should define an array $config that contains multiple arrays, one for each item in the $LOGIN_CONF array in conf.php. See the acp.php file for the LDAP or OpenID modules for an example. Each array in the $config array should be formatted as follows
array(
'title' => 'This is the title',
'description' => "This is a description for the setting",
'key' => 'conf_key',
'type' => 'string'
),
title is a field title that will be shown in the ACP, while description is the field description displayed. key corresponds to the array key in $LOGIN_CONF from conf.php for this setting. type tells IP.Board what type of setting this should be. Available types are 'yesno', 'select' or 'string'. If you are creating a select dropdown menu, you should also include another parameter 'options', which corresponds to the options you would pass to the output method formDropdown(). For example
'options' => array( array( 'value', 'Displayed Text' ), array( 'another_value', 'Other Text' ) ),
auth.php
This file is the only file truly required for your login module to function. The class name should be "login_(folder)", should extend login_core, and should implement interface_login. So, if your folder was "mylogin" your class definition would be
class login_mylogin extends login_core implements interface_login
Your constructor should be as follows
/**
* Constructor
*
* @access public
* @param object ipsRegistry reference
* @param array Configuration info for this method
* @param array Custom configuration info for this method
* @return void
*/
public function __construct( ipsRegistry $registry, $method, $conf=array() )
{
$this->method_config = $method;
$this->ldap_config = $conf;
parent::__construct( $registry );
}
$method is the normal login module configuration from the ACP, while $conf is the custom configuration options from conf.php. You should call parent::__construct to give login_core a chance to create the registry shortcuts (and anything else that may be necessary in the future).
You will need to define an authenticate() method that does the bulk of the work for the login method. It should accept three parameters: the username, the email address, and the plain text password.
public function authenticate( $username, $email_address, $password )
The rest of the function is going to be up to you to define, based on the needs of your specific login method.
The authenticate method is really the only method that you need to define. If the user authenticates successfully from your remote application but cannot be found in the remote database, you should call $this->createLocalMember to create the local member record. Ultimately, the local record member data should be assigned to $this->member_data, and you should set $this->return_code to a status code, and return true or false, based on whether user authenticates successfully.
The return codes that you can use:

• SUCCESS: User authenticated successfully
• WRONG_AUTH: User did not authenticate successfully
• NO_USER: User could not be found (note that it is generally better to use WRONG_AUTH - by not specifying to the user whether the identifier, e.g. the name or email address, or the password was wrong, you give malicious users less information to assist with brute force and dictionary attacks).
• MISSING_DATA: A piece of identifying data was missing
• FLAGGED_REMOTE: User must first login at the remote application to clear up an issue with the account

Note that you can update local data during the authenticate() method if you need to. e.g. if the user logs in successfully, and you have found the local record, but the email address associated with the local record does not match the one in your remote user storage, you can update the local user record's email address to match the remote storage. This is optional based on the needs of the login module.

Your login module may optionally also define a couple of other methods that IP.Board will call when appropriate. These methods can be used to help keep your remote user store and IP.Board in sync, as appropriate.

public function emailExistsCheck( $email )

Takes the $email parameter passed to it and checks if the email already exists in the remote user storage.

public function changeEmail( $old_email, $new_email )

Change $old_email to $new_email in the remote login storage.

public function changePass( $email, $new_pass )

Change the password associated with $email to $new_pass. Note that this password will be md5-hashed.

public function changeName( $old_name, $new_name, $email_address )

Change the username associated with $email_address from $old_name to $new_name.

public function createAccount( $member=array() )

Create an account with the supplied $member data (as corresponds to the members table in IP.Board) in your remote application

ACP Configuration

The last thing you will need to do is register your login module in the ACP. Login to the ACP and under the System tab click Log In Management. Click the button to add your login module, complete the form, and submit it. You can then drag n drop the enabled login modules to determine the order they should be executed in. This would allow, for example, IP.Board to first check the remote login module for the user, and then fallback to checking the local database. The last thing you will want to do is export the base configuration. Click the button next to your login module and click Export. Save the file to your login module's directory in admin/sources/loginauth.

Now, you can zip up the directory and share it with others if you wish. They'll just need to place the directory in their own loginauth folder, and then in the ACP the login method will show up at the bottom of the screen under "Other Available Login Handlers". They will be able to click the button next to your login module, hit install, and alter the configuration to suit their own needs. You can now, as well, edit the values from conf.php via the ACP if you have setup those files as well.

That's really all there is to creating a login module. If the needs of your module are basic you may even be able to get away with configuring the existing "external" module and using that. At the least, you can review the existing modules for an example of how to perform the necessary actions before creating your own.

This article will demonstrate how you can check if a member is currently logged into IP.Board and retrieve their data.

Firstly, include the initdata.php and admin/sources/base/ipsRegistry.php files and initiate the registry:

require_once( 'initdata.php' );

require_once( CP_DIRECTORY.'/sources/base/ipsRegistry.php' );

$registry = ipsRegistry::instance();

$registry->init();

You can now fetch the member's data by calling $registry->member()->fetchMemberData(); which will return an array of data on the currently logged in user.

If there is no member logged in, the function will return data for the guest user. To check if a user is logged in, just look at the member_id element - if 0, then the user is not logged in.

In addition to supporting external login modules, IP.Board can automatically support a plugin through the publicSessions class that can facilitate SSO integration (Single Sign-On). While the login modules can help tremendously, frequently if you are integrating your site and your forums you will want the user to be automatically logged in to the forums if they are logged into the site. In many cases this is possible, but requires hooking into the session authentication routines. IP.Board 3 supports a special plugin to do just that.

The first thing you need to do is create a file "sso.php" and place this file under /admin/sources/classes/session/. The file needs to contain a class "ssoSessionExtension".

You can add any of the following methods (all are optional) based on your needs

checkSSOForGuest: We have determined that the user is a guest. The method should accept one parameter $type, which will be set to either 'update' or 'create' based on whether we are updating or creating the session. You can use this to then further check to see if the user may be authenticated in your remote application, and take a different course of action, redirect the user somewhere to login, etc.

checkSSOForMember: We have determined that the user is a member. The method should accept one parameter $type, which will be set to either 'update' or 'create' based on whether we are updating or creating the session. You can use this to then further check to see if the user may be no longer logged in, recently banned, etc.

That's all there is to it really, but keep in mind that the API call can be called from a number of different scenarios in the sessions file - ultimately the end result should be the same: perform whatever actions you need to if the user is logged in or not logged in.

FINE

[svacant]

Questo è per sviluppare dei moduli di login per IPB e non bridge da un cms a IPB.

Si può fare in due modi:

-ti connetti al db di ipb e ti autentichi in maniera piuttosto grezza;

-utilizzi un sistema come quello del primo post (che non si capisce se sia compatibile con tutte le versioni o meno).

Quindi bisogna scegliere.

[najaru]

TI CONFERMO CHE è PER LA 3.

mi scuso per non capirci assolutamente nulla, io ti ho postato tutto quello che ho trovato, anche se per me è arabo.

direi che la seconda strada mi sembra decisamente meno invasiva.......

[svacant]

TI CONFERMO CHE è PER LA 3.

mi scuso per non capirci assolutamente nulla, io ti ho postato tutto quello che ho trovato, anche se per me è arabo.

direi che la seconda strada mi sembra decisamente meno invasiva.......

Provalo, se hai problemi o se funziona posta sul forum ufficiale così lo si rende disponibile.

login_ipb.zip

[najaru]

io ho uppato tutti i file. attivato plugin nell'admin.

ma ora che devo fare?

[svacant]

io ho uppato tutti i file. attivato plugin nell'admin.

ma ora che devo fare?

Nel template metti il tagcode {login_ipb} e dal pannello admin alla voce config lo attivi.

Per settare poi la path del forum comparirà login_ipb nel pannello admin (sotto config).

Dovrebbe funzionare.

ps nelle prossime versioni ci sarà anche la gestione degli utenti.

[najaru]

ok, ho visto il plugin dove mettere il path, ma non so cosa mettere

va bene /var/www/vhosts/invisionita.it/httpdocs/forum ?

[svacant]

ok, ho visto il plugin dove mettere il path, ma non so cosa mettere

va bene /var/www/vhosts/invisionita.it/httpdocs/forum ?

Ci va il path, questo che hai postato è un path quindi va bene

[najaru]

mi è apparso un secondo modulo di login al di sotto di quello normale, nella home del blog.

ma non mi funziona

a te risulta funzionante?

connettiti pure in admin (sono sloggato)

e imposta come ti sembra meglio.

poi prova.....

cosa dovrebbe fare?

dovrebbe loggarsi in automatico in ipb?

[svacant]

Ci siamo quasi.

Carica questi due files dentro framework.

utils.class.php

get.class.php

[najaru]

fatto.

devo provare? o provi tu?

comunque bisogna ovviamente essere sloggati da IPB.......giusto?

[BomAle]

domani provo il file nel primo messaggio di najaru spero funzioni

[BomAle]

si funziona (leggermente modificato), ho limitato il codice al login niente log out (disconnessione, lo può fare andando nel forum)

 

metodo.php

metodo.php contiene la classe e funzioni

 

login.php

login.php contiene il form e parte del php per effettuare il login con le "credenziali" inserite (username e password)