Questions/Comments on "A guide to the SMF integration hooks"

[Looking]

Thanks for the direction. I guess you are referring to:

Code Select Expand

setLoginCookie(60 * $modSettings['cookieTime'], $memberID, sha1(sha1(strtolower($regOptions['username']) . $regOptions['password']) . substr($regOptions['register_vars']['passwordSalt'], 1, -1)));

Based on my code I inserted it like this:

Code Select Expand

$regOptions = array(
   'interface' => 'guest',
   'username' => $txtUserName,
   'email' => $txtEmail,
   'password' => $txtPassword,
   'password_check' => $txtConfirmPassword,
   'auth_method' => 'password',
   'check_reserved_name' => true,
   'check_password_strength' => false,
   'check_email_ban' => false,
   'send_welcome_email' => false,
   'require' => 'nothing',
   'memberGroup' => 0,
   'just_registered' => 1,
);

$id_member = registerMember($regOptions);
if (is_array($id_member))
   die('Registration failed');
 
setLoginCookie(-1, $id_member, sha1(sha1(strtolower($regOptions['username']) . $regOptions['password']) . substr($regOptions['passwordSalt'], 1, -1)));

But not a go.

[Orstio]

Oh!

That's because there's no password salt.
You don't have any code to set $regOptions['passwordSalt'].

[Looking]

That's true but would I have to querry the database for that? If I am sticking with SSI $regOptions then I'll need something like

'passwordSalt' => (but what)?

Or am I going wrong here. Thanks.

[Orstio]

You need to use $regOptions['register_vars']['passwordSalt'].

[Looking]

I had that before and actually thought it was part of why it was not working. Adding it back did not help.

Here is my whole code for this:

Code Select Expand

global $context;   
require_once('/community/SSI.php');
require_once('/community/Sources/Subs-Members.php');

$regOptions = array(
   'interface' => 'guest',
   'username' => $txtUserName,
   'email' => $txtEmail,
   'password' => $txtPassword,
   'password_check' => $txtConfirmPassword,
   'auth_method' => 'password',
   'check_reserved_name' => true,
   'check_password_strength' => false,
   'check_email_ban' => false,
   'send_welcome_email' => false,
   'require' => 'nothing',
   'memberGroup' => 0,
   'just_registered' => 1,

);
   
$id_member = registerMember($regOptions);
if (is_array($id_member))
   die('Registration failed');
 
setLoginCookie(-1, $id_member, sha1(sha1(strtolower($regOptions['username']) . $regOptions['password']) . substr($regOptions['register_vars']['passwordSalt'], 1, -1)));

[Orstio]

Can you try using a positive number for the cookie time?

[Looking]

Thank you so much that worked!

I wonder why "-1" did not? Shouldn't that not give an more or less indefinite cookie?

[Orstio]

No, it gives a cookie that's already expired.

[Looking]

Thanks again.

[hlsantos]

Hi,  I read the "guide to the SMF integration hooks" and it seems pretty straight forward, except for one thing:

Where or what stock PHP file edit or create to begin the process, in other words where do I create?

   define('SMF_INTEGRATION_SETTINGS', .....

I got the idea that I didn't have to edit any stock PHP code and that it looks for a "optional hook" file that it will include if it exist, but that wasn't straight forward.  Load.php appearts to look for SMF_INTEGRATION_SETTINGS before it applies 'integrate_pre_include'.   I'm sure its simple and I just missed it.

Background:

If you can provide some guidance, it would be appreciate.

I'm the author of the WINSERVER (Wildcat! Interactive Net Server) intranet system, and we got some operators who wants to integrate SMF with WINSERVER.   But only at the authentication level. Not replace it but add the hooks, so when they login or logout into either system, they are synchronzed.

So if they login via SMF, a hook will authenticate the user at WINSERVER.  When he logs off, a hook will log him off WINSERVER.   And vice versa.   In addition, if the user registers with SMF, an account is also created at WINSERVER as well.  In short, they are sychronized authentication wise on both software.

I did the same thing with another customer using InstantForum.   It was almost two years, so I don't totally recall, but in that system, the hooking using optional "landing pages"  so if /loginpage.asp existed, then it will display that.  I used this optional page to authenticate against our winserver, when redirected back to loginpage.asp.  Similar with the other landing pages for register, logout, etc.

Based on what I read so far with the guide, it appears this will be easier since we have a PHP_WILDCAT.DLL extension that ties into the servers session context management and with the hooks, I will be able to work with the DLL.

So basically, all I need to know is what comes first here, the egg or chicken - where do I define the settings for the hooks?

Thanks

Hector

[Orstio]

You do it in your own file.

For your particular application, I would probably skip the SMF_INTEGRATION_SETTINGS and write the values directly to the settings table in the database.  That way, integrate_pre_include can be the file you use for the code for all the other hooks.

[hlsantos]

Hi Orstio,

Please forgive me, I am 500% new to your software, but not to programming.  "do it in your own file".  Ok, but how does that file get integrated by SMF?   Do I edit /index.php?   /Settings.php?   

When I give the "end product" to the operators, I want it plug and play. I don't wish to edit any stock files in SMF, unless that is what it takes.

I want to explore all methods, as you suggest with your expertise.  But I have not yet learned the SMF framework, flow of php scripts, etc.  So if the SMF_INTEGRATION_SETTINGs method is good enough to get me started, see some results, better understand the flow, then I can explore going more directy as you suggest, and I will if thats the better method.

I just need to get in the pool to get started.

What I am doing right now is adding this DEFINE to the top of the settings.php file.   Is that ok?

Again, my preference is not to edit any of stock files because if the operators upgrades to new SMF versions, I don't want to get into version control issues.

Thanks

Hector

[Orstio]

Adding it to index.php or settings.php should be fine then, yes.

What I was suggesting you do was add the variable=>value pairs to the smf_settings table instead of having the hardcoded SMF_INTEGRATION_SETTINGS.  Both methods work, but the former requires no edits to the code.

[hlsantos]

Ok, Yes, I just read the Load.php code to see how it merged the optional SMF_INTEGRATION_SETTINGS with $modSettings and then read how earlier in the reloadSettings() function how is creates $modSetting from the smf_settings table and thought about adding a new field 'integrate_pre_include.   Thanks for confirming this method. This should be good enough to get me starting.  I appreciate the fast response.

You might wish consider a small note update to the guide for this subtle missing point for new guys working with SMF. 

PS: Great software!

[hlsantos]

Hi Orstio,

Ok, I got the basic coding requirements to synchromized SMF login, logout and register with our backend server.

Give me give the coding pointers for the reverse direction?

Explanation:

Our backend is a 100% intranet - Private by default, authentication required to do anything with the exception of a '/public/'  alias, if used, it doesn't force authentication.   The /public alias puts a folder on the backend where they can stick any public files, including applications, like PHP.    So in this case, the operator installed smf under the server side \doc_root\pub\smf folder thus allowing him to use SMF independent from our authentication system, with the url   "/public/smf"

However, if smf is installed under \doc_root\smf, then the url, /smf, will force an authentication before that page will be served.

So basically, whats the recommended way to wrap the smf login, logout, register so that our server code can transparently  automate the three basic processes in SMF?

I guess this required setting the $php_session variables, adding a session record to the sql table, etc?

hmmmm?  just basically call login2(), logout(), registerMember() with the properly prepared parameters?

thanks

[Orstio]

Calling login2 or logout from external will result in a session verification error.

Since SMF relies on cookies to determine login status rather than sessions, you are better off using the cookie directly for login and logout.

If you download the Mambo bridge from the downloads page, you'll see in the files SMF_Login, SMF_Logout and SMF_Register how I handled passing these three items to SMF from an external system.  The files are fairly small and straightforward if you can read PHP.

[hlsantos]

Yes, I downloaded the provided examples to see how the various logics.  I'm going to put the this 2nd WINSERVER to SMF authentication to the side for now to get the initial project SMF to WINSERVER auth synchronization done per customer request.

Question:

When the integration is stable (meaning the two databases are in sync),  the smf register logic will begin the process.  I have to confirm this, yes, I just did a quick register testuser, the plain text password is passed to the integrate_register() function within the $regOptions array passed. 

I plan to use the basic three $regOptions[] parameters:

   $regOptions['username']
   $regOptions['email']
   $regOptions['password']  plain text password
   $regOptions['register_vars']['passwd']    hashed password

to register the new account at at backend.

This will work, but the sychronization "might" be off for "errors".   I noticed that registerMember() calls integrate_register() but it has no result logic flow.

In other words, if the registration fails at the backend, it continues.

I guess I can modified the registerMember() function to provide a  functional true, false result when it calls integrate_register();   false means do not continue with SMF database registration.

But would there be another way?

I guess, the better way to discribe this is a need for:

       bool integrate_validate_reqister(string $username)

which is called at the top of registerMember to verify that the backend user name is not already taken.  It would work similar to integrate_validate_login() function which your notes indicate allows for a failed break out.

I hope this made sense.

Thanks

[Orstio]

Yes, I see your dilemma.

Is it PHP 5.x?  You could always throw an exception to kick out of the workflow and produce an error message.

[hlsantos]

Orstio,

If you download the Mambo bridge from the downloads page, you'll see in the files SMF_Login, SMF_Logout and SMF_Register how I handled passing these three items to SMF from an external system.  The files are fairly small and straightforward if you can read PHP.

Ok, I looked at it.  Excellent logic to work with.  But it still has the problem, unless there is something I missed where if the remote registration fails, there is no captured logic to abort or revert the SMF registration.

I had this same issue with InstantForums where the databases are now out of sync.  No new account recorded on the backend.   This was one of the two instances where I had to modified the source code to do a "pre-registration check" before continuing the the logic.

Am I missing something in SMF or something already available to provide this?  remember the goal is to work with the your hook system - no modifying to stock code if all possible.

In the mean this, this is what I did to subs-members.php:

Code Select Expand


// Call an optional function to validate the users' input.
if (isset($modSettings['integrate_register']) && function_exists($modSettings['integrate_register']))
   {
       //-----------------------------------
       // WCSMF Registration Check, 6.3.453.4
//$modSettings['integrate_register']($regOptions, $theme_vars);
      if (!call_user_func($modSettings['integrate_register'],$regOptions, $theme_vars))
{
    fatal_error(sprintf("Wildcat! User Name not valid: %s",
                         htmlspecialchars($regOptions['username'])), false);
    }
       //-----------------------------------
   }


I'm assuming fatal_errors aborts/redirections to some graceful error display.  I having tried it yet.

I see your last message, Nice the SMF smartly detected a new post was available.

We only support PHP 5.2.5 to 5.3.0 right now, more specifically, our extension is only compiled for this versions currently.   

So you think if my wrapper throws an exception it will suffice here?

If not,  can I suggest this change (make it a bool function) or whatever you think is best wish item for before 2.0 goes gold? 

THX

[Orstio]

I haven't been on the SMF team for almost two years.  You're asking the wrong guy to make changes.

What do you see as a potential for the username to fail in your system but not in SMF?

ETA -- I'd be wary of doing this with any version of 2.0 at this time.

http://www.simplemachines.org/community/index.php?topic=374107.0

Not all the integration hooks are functional in RC3.  For integration, stick with 1.1.x until there's some progress.