Ladies and gentlemen,
May I present, Accounts Addon for WoW Roster v2! Ok, so it's not finished yet. However I've been working very hard to get this addon working. What will it do? Well, that's all listed below:

- Adds user registration
- Adds user activation
- Adds user login
- Remembers username and password - Auto Login (requires cookies)
- Adds a user profile page
- Allows users to manage all their characters/guilds on a roster
- Adds some user access control

What's the current status of this addon? At the moment, the addon is still being developed. But we have built an extensive user class for roster, and built most of the forms for login, registration, activation, access, and lost passwords. I am still working on fixing bugs with the activation system, as well as the account management and admin pages.

How long before this addon is finished? Well, it's hard to say, but I'm shooting for around the time Roster v2 goes final. If everything works well, this addon could become the long awaited user system for WoW Roster.

Screenshots:

Accounts Registration Screen


Accounts Login Screen


Accounts Deny Access Screen

hmm very interesting work we have here...

Ooooooo, shinny

So you did what we didn't want/have time to do for Roster
Thanks

I have one question
What files in the Roster core need to be modified?
I ask so we could possibly tweak the Roster core to allow addons to take over the user auth (good for CMS integration too!)

How are you handling the accessing of different pages? Are you modifying the code for each addon to include permissions?
This is what I had to do on my guild site to get things working the way I wanted.

You wouldn't have to edit each file
You could have an entry in the roster_addon table that holds the access info
Then index.php could check that field for the requested addon and give permission accordingly

Then the auth addon could handle all of the permissions settings giving basic settings for each addon
Of course addons could enter their own access data in the field for more precise controls

zanix wrote:You wouldn't have to edit each file
You could have an entry in the roster_addon table that holds the access info
Then index.php could check that field for the requested addon and give permission accordingly

I was actually just sitting here brainstorming on how to do that.
Waiting anxiously for this addon to see how it works.

boyo wrote:I was actually just sitting here brainstorming on how to do that.
Waiting anxiously for this addon to see how it works.

Me too

I personally doubt addon-level permissions are all that useful. It's better to have the addon author implement it himself, since he can give more accurate configuration.

ATM for user access control it will just be on this addons pages. However I hope to make it as simple as adding a line or two of code to a page to make access permissions work. Unfortunately it's more like 5 or 6 right now. But I also thought of implementing it through the roster index and possibly using scope, addon, and page variables to determine which page is being viewed and weather it has permissions. But I think that method would require me to give user access controls it's own class.

Zanix, currently there is only one core change I'd like, but don't require. That is the inclusion of @mysql_result in the db class. For some reason fetch and fetch_all wouldn't return the correct results and MySQL kept giving errors. Of course you could just add the whole user and profile classes to the core.

I hope to upload the addon to the SVN very soon so other devs can see it, play with it, add to it, etc.

I haven't noticed any problems with the dbal myself. Can you post something so we can reproduce it?

Also, the authorization api is currently restricted to rank-based auth. I don't want to completely remodel it, and that's probably unhelpful for you as well, but if you've got specific suggestions they can probably still be inserted for 2.0.0

Here's an example of where I had to use @mysql_result to get the db to properly output the info:

Code: Select all

function checkUser($pass = "") {
    global $roster, $addon;
    
    switch ($pass) {
        case "new": 
        $sql = sprintf("SELECT COUNT(*) AS `check` FROM %s WHERE `email` = '%s' OR `uname` = '%s'", $this->userTable, $this->userEMail, $this->user);
        break;
        case "lost":
        $sql = sprintf("SELECT COUNT(*) AS `check` FROM %s WHERE `email` = '%s' AND `active` = '1'", $this->userTable, $this->userEMail);
        break;
        case "new_pass":
        $sql = sprintf("SELECT COUNT(*) AS `check` FROM %s WHERE `pass` = '%s' AND `uid` = %d", $this->userTable, $this->userPass, $this->uid);
        break;
        case "active":
        $sql = sprintf("SELECT COUNT(*) AS `check` FROM %s WHERE `uid` = %d AND `active` = '0'", $this->userTable, $this->uid);
        break;
        case "validate":
        $sql = sprintf("SELECT COUNT(*) AS `check` FROM %s WHERE `uid` = %d AND `tmp_mail` <> ''", $this->userTable, $this->uid);
        break;
        default:
        $password = (strlen($this->userPass) < 32) ? md5($this->userPass) : $this->userPass;
        $sql = sprintf("SELECT COUNT(*) AS `check` FROM %s WHERE `uname` = '%s' AND `pass` = '%s' AND `active` = '1'", $this->userTable, $this->user, $password);
    }
    $result = $roster->db->query($sql) or die($roster->db->errno().$roster->db->error());
    if (@mysql_result($result, 0, "check") == 1) {
    return true;
    } else {
    return false;
    }
} 

It may work using fetch or fetch_all, I might just have to re-write the queries.

I also planned on making a function in the user class to get the auth info from the db based on the group_id. That way it can interface with the authorization api so you won't have to remodel it.

For those queries, I'd recommend $roster->db->query_first($query). It's designed for cases like this, where the query only returns 1 row with 1 column.

Code: Select all

return (bool)$roster->db->query_first($sql);

Should work fine in your case. DB functions will either return false or die if they fail, depending on the $roster->db->error_die() setting.

Thanks PleegWat! I'll make the changes in the code.

Hi mdeshane, good work!

One question can be the "authorization" do it in mind modulable ?

At moment yes is, a register > login / reminder > profile > authentication process > rights > logout ..

But can be disable register and make login modulable to get information from another systems ?
like phpbb2,3 dragonfly,phpnuk,joomla,smf,vbulletin,etc..

Its NOT a PLEASE MAKE THAT, its ONLY a GET IN MIND and think about possibility to get LATER login/rights from other DB auth styles with the SAME module with little plugs. I known its better take care about these "options" before and not later to simplify the remake process to add these features.

Good job ^^

That is exactly one of the things I've been thinking of Subxero! Since I also make the Xoops port I figured I'd make a plug-in for that, and I think I'll leave it up to community members to write plug-ins for their various CMS systems that they use. Unfortunately I'll have to write documentation so they can build the plug-ins, but it's better than me doing all of them.

Maybe I can build the plug-in system much like the addon system for the roster. But that might be something for a second release of this addon.