By setting the account activation to ‘true’, users will instantly be able to use their account. However, if you were wishing to just by-pass the activation email, and still have an admin review the account, then there is a setting in the config file to suspend all new accounts.
A little off topic regarding not sending emails from the dev environment.
If the reason you’ve not got this running is the associated hassle setting it up (Setting up Mercury via Xampp was a nightmare for me), may I recommend try installing hmailserver, you can even associate the SMTP with a GMail account just for testing.
Another mail server I saw just yesterday was Mailcatcher, but I haven’t personally tried this yet.
—————————————————————————————-
I’m interested in your comments regarding the database keys.
You’re right that the foreign key constraints should be defined, I’ll add this with my next round of tweaks.
Regarding some of primary keys being redundant, could you elaborate a little more on which fields you are referring to?
What I do for localhost email is just write the contents of the email to a log file, one for each email. It works well because you get to check for php errors.
Thank you guys for your quick reactions!
For now I have found a solution for the mail problem: I installed ssmtp on my Ubuntu server machine and configured it to send mail using the SMTP server of my provider.
And this works, though I have no been able to deploy the demo version from my local machine to the server machine. The URL (***.localhost) is hardcoded in all controllers and I just had to change it each time when testing on my local machine or on the test server, which is a different machine on the local network.
Even in the comment is written that is os no good practice and I see really no reason to hard code a URL or directory in all controller classes while the base url is already defined in the config file.
I am struggling with the rest of the code, too. I do not understand the separation between the normal and lite versions of the code, a very basic function as login() is defined in the Flexi_auth library class, so what is the point in defining a _lite superclass which has no login functionality defined so is hardly usable by itself?
Or is the lite version meant to be used only by the controller methods for already logged in users?
To make my confusion worse, when installing the non-demo version, the two model classes (flexi_auth_lite_model and flexi_auth_model) do not define a login() method. So do I need to copy the code from the demo model classes?
SO right now I am utterly confused by this code and the distinction between lite/not-lite as well as between demo/nondemo versions.
I will give it one more day before deciding to go on with it or get back to the original IonAuth.
The split between the ‘lite’ library and the ‘main’ library should be considered a feature, it is not a requirement.
Whenever you include the main library, it extends the lite library meaning functions in both versions are available to you.
If you want to include the main library on every page, that is fine, it will just consume a little more memory on every page load.
The easiest way to look at the purpose of each library version is this:
+ The lite library is used to getting user data, and for checking user credentials - things that you are likely to need to do on every page load - e.g. checking whether a user is logged in and then displaying their name.
+ The main library is the work horse, performing actions like login, registration and forgotten password functionality. You are likely to only need to use these functions when a specific action happens, like a login form being submitted.
Regarding you not being able to find the login() method in either model, its in the ‘flexi_auth_model’, but there is no reason for you to change any data within any of the flexi auths model or library files.
The demo models are purely for the examples within the demo site and have no part in how flexi auth works - they are examples of how to use flexi auth functions within a website.
——————————————————————
Regarding the ‘base_url’ being defined in each controller, this is purely for the purposes of the demo so that it is easier for users to quickly get setup and running.
The 3 vars that are set within each controller are defined there so that they are available for creating href link paths within Views.
It is not used in the same was as the ‘base_url’ defined within CI’s config.php file that is used for routing.
I would presume there is an incorrect setting somewhere in the flexi_auth config file, but without looking at your setup it hard to know what the specific problem is that’s causing the error.
What I would suggest is that you start a brand new bare installation of CI and flexi auth, then run through the installation guide @ http://haseydesign.com/flexi-auth/user_guide/installation
It is very important that this guide is closely followed, as the slightest omission can cause errors.
Then just follow examples within the demo files on how to setup your controller and a basic view file.
Do not get complicated from the start, just have a simple form within the view file that gets a user to login and see how it goes.
To give you some example data, you may want to use the sql dump and the flexi auth config files from the demo to give you a head start.
Once you get the basics working, then customise the database tables and config file settings to your requirements.
@haseydesign
I found the issue. the errors come when ‘form_validation’ library is auto-loaded in beginning. Is there a specific reason for this error or is it still my installation issue.
The split between the ‘lite’ library and the ‘main’ library should be considered a feature, it is not a requirement.
Whenever you include the main library, it extends the lite library meaning functions in both versions are available to you.
If you want to include the main library on every page, that is fine, it will just consume a little more memory on every page load.
The easiest way to look at the purpose of each library version is this:
+ The lite library is used to getting user data, and for checking user credentials - things that you are likely to need to do on every page load - e.g. checking whether a user is logged in and then displaying their name.
+ The main library is the work horse, performing actions like login, registration and forgotten password functionality. You are likely to only need to use these functions when a specific action happens, like a login form being submitted.
Regarding you not being able to find the login() method in either model, its in the ‘flexi_auth_model’, but there is no reason for you to change any data within any of the flexi auths model or library files.
The demo models are purely for the examples within the demo site and have no part in how flexi auth works - they are examples of how to use flexi auth functions within a website.
——————————————————————
Regarding the ‘base_url’ being defined in each controller, this is purely for the purposes of the demo so that it is easier for users to quickly get setup and running.
The 3 vars that are set within each controller are defined there so that they are available for creating href link paths within Views.
It is not used in the same was as the ‘base_url’ defined within CI’s config.php file that is used for routing.
Hi, thanks again for your reply. I think I am getting things a bit better now.
I made a sketch for myself to clear up some issues, I understand now that the flexi_auth_model class just extends the flexi_auth_model lite class and for the first tests I can just use the subclass version.
Other issue was the demo model classes which I first considered to be a replacement for the core model classes, but now I understand that they are just another layer:
Summarized the layers can be shown as follows:
Remains the issue of the 3 vars in each controller, I think is is still messy that they should be modified in 5 places or so, and a constant could be better defined for it, but maybe I am missing something yet…
After talking to my project leader we continue evaluating FlexiAuth and will tryo to set up a basic register/login system next weeks. So I will keep you informed…
This is what I meant by a redundant unique index, a field which is defined as primary key is unique by definition, so the UNIQUE KEY constraint is superfluous.
This is also found in some other tables.
A potential more severe problem is:
CREATE TABLE `user_privilege_users` (
`upriv_users_id` smallint(5) NOT NULL AUTO_INCREMENT,
`upriv_users_uacc_fk` int(11) NOT NULL,
`upriv_users_upriv_fk` smallint(5) NOT NULL,
PRIMARY KEY (`upriv_users_id`),
First, I do not see the added value of an auto increment key in a link table. The combination of both FK field is already unique and perfectly suitable as primary key.
Worse, the upriv_users_id PK field, if used, should not be a smallint. One of the foreign key fields refers to the User Account table and because each user can have more privileges, the potential number of entries of this link table is higher than the number of users.
So IF a separate auto-increment PK field is used, it should at least be as big as the biggest of the FK fields, so it ahould be an INT and surely not a SMALLINT.
I try the live demo (http://haseydesign.com/flexi-auth/auth_lite/demo) but I am not able to log in as public user (logging in as the two others, admin and moderator, does work however.
Can this be confirmed?
Hey Klausch,
You are indeed correct. Something obviously must have gone awry around launch.
I’ve updated both, the live demo and the Github repo to fix this glitch. The login details remain the same.
Thanks again for the quick reaction!
I have downloaded the new zipfile from the Github repo (haseydesign-flexi-auth-806f08e.zip), but when recursively comparing the content with the previous version (b639cc8), no differecnes are reported, except for the file dates…
MAybe I am missing something, but can you tell what has been modified between those two releases?
And one more issue, I have developed a first user registration system for our website, I do not use a separate custom user table but have extended the existing user_account table, which should be perfectly legal accoding to the documentation.
When trying to register a new user, trhe following errors are issued:
A PHP Error was encountered Severity: Notice Message: Undefined property: stdClass::$tbl_custom_data Filename: models/flexi_auth_model.php Line Number: 389
A PHP Error was encountered Severity: Warning Message: Invalid argument supplied for foreach() Filename: models/flexi_auth_model.php Line Number: 389
A PHP Error was encountered Severity: Notice Message: Undefined variable: row_id Filename: models/flexi_auth_model.php Line Number: 420
The errors originate from the fact that in flexi_auth_model.php, the method insert_custom_user_data(...) is called but no variable [‘database’][‘custom’] is defined in the config file.
Already before commiting, the following error was shown. I remember I had seen this error before when running the demo and had commented out line 86, but this was not the solution because the $this->auth->tbl_custom_data is used in the insert_user method.
A PHP Error was encountered
Severity: Notice
Message: Undefined index: custom
Filename: models/flexi_auth_lite_model.php
Line Number: 86
($this->auth->tbl_custom_data = $this->auth->auth_database[‘custom’];)
I think a solution might be defining the [‘database’][‘custom’] variable as an empty array, but this is not mentiond in the confi file so I would like to hear your opinion.
You would only need to update this if you’re using the demo sql data.
In which case if you could also just use the following sql to update your existing database data.
UPDATE `user_accounts` SET `uacc_password` = '$2a$08$GlxQ00VKlev2t.CpvbTOlepTJljxF2RocJghON37r40mbDl4vJLv2', `uacc_salt` = 'CDNFV6dHmn' WHERE `uacc_id` = 3;
——————————————————————————
Regarding the error with the custom user data, I think you’re using the wrong function for the table you are targeting.
The ‘insert_custom_user_data()’ and ‘update_custom_user_data()’ functions are only for updating data within custom user tables that you have added.
If you have just added additional columns to the main user account table, then you need to define the column name and value via the ‘user_data’ argument in both the ‘insert_user()’ and ‘update_user()’ functions.
So if for example you had a custom column within the main user account table named ‘column_1’ and ‘column_2, you would update that column with the following code.
$user_id = 101; $user_data = array('column_1' => 'Column Data #1', 'column_2' => 'Column Data #2');
update_user($user_id, $user_data);
Note: Ensure you have defined these custom columns in the flexi auth config file via the following setting:
