I implemented my own auth routine for our internal single-signon system and it went mostly well. The API itself is clear and easy to use. There are some problems I had though:

1. includes/auth/auth.php - _createBugdarUser()

Logging worked fine once I wrote my routine - I could see as much using a few print_r() statements... but the _createBugdarUser() function wasn't inserting a complete database record... several core fields were null. Around line 281 I had to change two *minor* things:

$authDb was changed to $authdb.

foreach ($this->fieldMap AS $bugdar => $authdb)
{
$user->set($bugdar, $this->authUser["$authdb"]);
}

Then the account syncing worked as expected.

2. template/userctrl.tpl needed updating: it doesn't display the "displayname" field if you use anything other than "default"... but then you can't update your bugdar settings because it complains that displayname can't be null. I added these lines underneath the IF condition testing to see if the auth routine is "default":

<if condition="$bugsys->options['authmethod'] != 'default'">
<input type="hidden" name="displayname" value="{$userinfo['displayname']}" size="25" maxlength="250" />
</if>

This allowed me to save changes to my profile.

3. I wish there had been a way to customize the "email" label on the login form because while you can use a username or anything you like... you have to manually edit the templates (AFAIK) to have it say "username". Minor annoyance but when you release an update I'm going to have to remember to update the login.tpl file again.

I haven't run into anything else yet...

For what it is worth, I've tried nearly every bug/issue tracking system out there and this was the first one that made me stop writing my own - the auth API was key to this but the interface was clean (though I've heavily modified the .css styles to my own liking) and has just the right feature set for our organization. I kinda wish I could use Markdown as the formatting plug-in for textareas but that's a small thing.

Thanks for the feedback on the authentication API. I tried to make it abstract as possible and I'm glad it worked mostly well for you.

1. I have fixed this for the next release in r1603 (trunk) and 1604 (branch).

2. This is actually the desired behavior. If you look in includes/auth/auth.php around line 70, you can see that the field "displayname" is one that should be mapped from your authentication database. If you want, you can easily remove the <if> conditional around the lines. It's just that the majority of authentication providers have their own name that usually people want to keep synced.

3. I can make it so that this text is localized in the auth API instead of a template for a future release.

Regarding #2 - Mapping of the displayname field and validation errors on profile changes.

I do have displayname mapped in auth API module but the form was throwing an error still that displayname can't be null. I don't see anyway it would have known what the displayname was unless there's a hidden field with the data in it. So I *think* this is a bug for those of using anything but auth_default.

Thanks for looking into this Robert.

Ah. It's because in the save process in userctrl.php there is no condition around the saving of the information. To fix this, you'll want to open userctrl.php and find line 141. I'd suggest commenting it out until the next release when I think of a more elegant solution to fixing this with mapped fields.

Is it just me or does this section of "_createBugdarUser()" in auth.php have a case type-o with $authdb.

$user = new UserAPI($this->registry);
foreach ($this->fieldMap AS $bugdar => $authdb)
{
$user->set($bugdar, $this->authUser["$authDb"]);
}

Bernie: Yes, in the initial report this was addressed. This has already been fixed in SVN but a new release hasn't been done with the fix in it, yet.

I made the changes mentioned but was still getting an error message regarding a blank userid. For people that didn't have any cookies already set and logged in via bugdar, the error wasn't critical. However, for those already logged in via vBulletin, they would get a critical bug that would only show a bunch of errors on the screen. If they were to refresh the page at that point, the page would load up fine.

I dug through the code to see if I could find the problem and I think I may have tracked it down. Or at least, after adding in the line of code, I'm not longer getting the error messages under either scenario anymore.

In the _createBugdarUser() function in the auth.php file I added the following:

Underneath

$user->insert();

I added

$user->set('userid', $user->insertid);

After I did that, everything works perfectly.

any chance we can get Invision Power Board Website Integration (IPBWI) added?
http://pc-intern.com/projekte-5676.html

See my post on the forum