YAAS :: Yet Another Authentication System :: 0.0.1

[eluser]tdktank59[/eluser]
UPDATE: November 18 2011: Currently working on a full Version 1 of this. However it is moving slow since I have to pay the bills.
I will release as soon as I can.

Until then use asis, I will not be making updates. Sorry



YAAS: Yet Another Authentication System

UPDATE LOG:
6/24/2009 - Initial Beta Release - Version 0.0.1
6/8/2009 - Preview Release

================================================================================
UPDATE: 6/24/2009 - Version 0.0.1

Release Info:
This is a full featured release. It has yet to be thoroughly tested however. Things that are still missing are: Paypal Integration for subscriptions. Enforcement of Start/End Dates assigned to permissions. Email templates are not completed yet. But functionality is there to support them. (I think)

The Idea
YAAS wont be your basic auth system. It will be running on top of a few things

1. Data Mapper DMZ Edition I started using ORM at work and it makes things simple. Thus why I want to use it. Also in my opinion speeds up development time.

2. View Object. A partials rendering templating engine. Works kinda like the view loader with CI. However supports rendering partials to areas on a template. Im open for suggestions here but smarty is out of the question (too much overhead...)

Now onto the fun stuff!
Here are the goals of this project as of right now

1. Role based restriction based on Class => Method relations in a sense you can create a artificial CRUD environment. Also will support subscriptions (with pay pal integration) with the use of Start and End times.

2. Individual user permissions. Same as Roles just directly to the user.

3. Move the config to the database, but still have the config file for defaults

4. Login, Registration, Forgot password. Your basic Authentication Library stuff...

5. Anything you guys can think of or I think of while doing this!

================================================================================
Installation
1. Drag and drop the application folder into your appropriate place. (Normally system folder)
2. Import the database
3. Make sure all your config files are setup.
4. Add datamapper, database, session to your autoload file for libraries. (system/applications/config/)

Requirements
All are included with this release
Libraries: * marks CI Native
1. database*
2. datamapper
3. session*
4. view
5. yaas

Helpers
* marks CI Native, ** Marks Extended
1. array**
2. string**
3. url*
4. date*
5. cookie*
6. email*

Yaas should load most if not all of these...

Downloads:
Releases:
Current Release 0.0.1

User Guide * In Development However the source is pretty well documented *

[eluser]Edmundas Kondrašovas[/eluser]
Wow, I really like your ideas! Especially the permissions concept. I'm just not sure why you need a temporary table for unactivated accounts. You could just add an additional boolean field on the original users table called "activated" or something like that. On the other hand, maybe there would be more flexibility available with temp table. Either way, I don't think there is a big difference and I am not in position to decide.

Good luck!

[eluser]tdktank59[/eluser]
The reason for the temp table is it can give more accurate figures for registred users.

The primary purpose of this project is to run on my game im creating. However alot of people sign up but dont actually play the game.

When a user signs up they get a few tables for there stuff (1 row in each table)
user (contains username, password that sort of stuff)
user_data (the games data, level, experience etc...)
user_info (name, intrests, hobbies, profile, etc...)
user_config (show profile, timezone etc...

So by only adding the user to a temp table until they activate there account it removes the other 4 tables... And allows me to track who actually activated there account without having to say check for the flag.

Make a bit more sense?


Any features you would like to see that are not there?

WOops forgot to add DB/Cookie sessions

[eluser]Colin Williams[/eluser]
What is the data scheme for a user? How easily extensible is it?

[eluser]tdktank59[/eluser]
This is what im using at the moment

Code:

CREATE TABLE IF NOT EXISTS `user` (
  `user_id` int(10) unsigned NOT NULL auto_increment,
  `username` varchar(255) NOT NULL,
  `email_address` varchar(255) NOT NULL,
  `password` varchar(255) NOT NULL,
  `register_date` int(10) unsigned NOT NULL,
  `account_verificiation_code` varchar(255) NOT NULL,
  `account_status` int(11) NOT NULL default '1',
  `account_status_reason` text NOT NULL,
  PRIMARY KEY  (`user_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=4 ;

--
-- Table structure for table `user_data`
--

CREATE TABLE IF NOT EXISTS `user_data` (
  `user_id` int(10) unsigned NOT NULL auto_increment,
  `donator_days` bigint(20) unsigned NOT NULL default '0',
  `level` bigint(20) unsigned NOT NULL default '1',
  `experience` decimal(10,4) unsigned NOT NULL default '0.0000',
  `currency_main` bigint(20) unsigned NOT NULL default '1000',
  `currency_secondary` bigint(20) unsigned NOT NULL default '25',
  `vital_one` bigint(20) unsigned NOT NULL default '0',
  `vital_two` bigint(20) unsigned NOT NULL default '0',
  `vital_three` bigint(20) unsigned NOT NULL default '0',
  `vital_four` bigint(20) unsigned NOT NULL default '0',
  `vital_one_max` bigint(20) unsigned NOT NULL default '0',
  `vital_two_max` bigint(20) unsigned NOT NULL default '0',
  `vital_three_max` bigint(20) unsigned NOT NULL default '0',
  `vital_four_max` bigint(20) unsigned NOT NULL default '0',
  `stat_one` decimal(10,4) unsigned NOT NULL default '10.0000',
  `stat_two` decimal(10,4) unsigned NOT NULL default '10.0000',
  `stat_three` decimal(10,4) unsigned NOT NULL default '10.0000',
  `stat_four` decimal(10,4) unsigned NOT NULL default '10.0000',
  `stat_five` decimal(10,4) unsigned NOT NULL default '10.0000',
  PRIMARY KEY  (`user_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=4 ;

--
-- Table structure for table `user_group`
--

CREATE TABLE IF NOT EXISTS `user_group` (
  `user_id` int(10) unsigned NOT NULL,
  `group_id` int(10) unsigned NOT NULL default '1',
  UNIQUE KEY `user_group` (`user_id`,`group_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

--
-- Table structure for table `user_info`
--

CREATE TABLE IF NOT EXISTS `user_info` (
  `user_id` int(10) unsigned NOT NULL auto_increment,
  `aim` varchar(255) default NULL,
  `yim` varchar(255) default NULL,
  `msn` varchar(255) default NULL,
  `icq` varchar(255) default NULL,
  `skype` varchar(255) default NULL,
  `website` varchar(255) default NULL,
  `avatar` varchar(255) default NULL,
  `signature` text,
  PRIMARY KEY  (`user_id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=4 ;

--
-- Table structure for table `user_verification_code`
--

CREATE TABLE IF NOT EXISTS `user_verification_code` (
  `user_id` int(10) unsigned NOT NULL,
  `email_address` varchar(255) NOT NULL,
  `account_verification_code` varchar(255) NOT NULL,
  UNIQUE KEY `user_id` (`user_id`),
  UNIQUE KEY `account_verification_code` (`account_verification_code`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

However I will be changing this with my new ideas that I came up with last night. (its an old database)

Basicaly the user table is soly responsible for the user authentication

and everything else extends that user_info for contact info and so on. So basically just add another table is as simple as it gets

[eluser]Edmundas Kondrašovas[/eluser]
[quote author="tdktank59" date="1226117618"]Make a bit more sense?[/quote]
Absolutely. Thanks for the explanation, I knew there was an idea behind this temp table. :-)

[quote author="tdktank59" date="1226117618"]
Any features you would like to see that are not there?
[/quote]
I can't think of more ideas at the moment, since I don't really develop very complex or large account management systems and I don't have enough experience in this. However, my advice would to make your Authentication System as flexible as possible (so that others could extend or modify it without big code changes) and not just feature-full if you know what I mean.

[eluser]Colin Williams[/eluser]
I guess the problem with "it's as simple as adding a table" is that it's not that simple. Any extension to the user object in this fashion means having to write CRUD code to correspond with the new extensions. The API breaks down.

[eluser]tdktank59[/eluser]
I don't follow what your talking about.

If you add a new application, module what ever it may be. You don't extend the user table. You add a new table, This new application then would (could) have references to the other tables, However the new application would run any of its new data from its own table.

All you would have to do to make the table "friendly" with the system is to add the correct foreign keys to the new table in this case it would be user_id. The creator of the new application would have to setup the proper scripts to have the table populated with what ever data is needed.

So if you can explain to me what you are talking about here that would be appreciated. My number one goal (or two i forget what im up to lol) is to create a extensible library that can be added onto with little if no effort.

[eluser]Colin Williams[/eluser]
Just pretend I don't know what I'm talking about on this one. No use.

[eluser]tdktank59[/eluser]
Well let me know... Im trying to make this extensible and if this could pose a problem I would like to try and over come it...