• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
flexi auth - A user authentication library for CodeIgniter

And I have a bunch of more issues... hope you appreciate my input Smile

It is about the email actication. When clicking the link in the activation email, the function
auth->activate_account(...)  (line 179)
is called, which is delegated to
flexi_auth_model->activate_user($user_id, $token, TRUE); (line 888)

Although the documentation of this function tells the return type is "void", it is actually the boolean result of this function which tells us whether activation was succesful or not.

However, the return value is ignored in the controller method and the caller is redirected to the index page (and from there to the login page).
I think it would be better to use the Boolean return value in a view which tells whether activation was succesful or not. And in the case of a succesful actication, offer a link to the login page.

I am about to implement this, the library class needs not to be modified for this, but the controller does. And of course I am interested in your opinion about this!

I noticed that the logout function was not working, the call to auth/logout raised an error and the session row was never deleted.
After som research I found the culprit was in the contructor of the auth controller, which I copied from the demo:

if ($this->flexi_auth->is_logged_in_via_password() && uri_string() != 'auth/logout') {

The parentheses after the call to uri_string are missing! Adding them solved the problem.

I have noticed that when signin up as a new user, if the email notification does not work, the Flexi_auth->insert_user(...) function returns with FALSE at line 589, but the inserted record remains in the database. I think that in this case, it should be deleted. BEcause we have some problems with the mail server, we always have to delete the record by hand when the confirnation amil is not send.

In my opinion, the insert of the user and the sending of the email should i fact be considered as one transaction. I think on this level we cannot make use of a real DB transaction because sending the email is not a DB operation, but at least the insert should be undone when email sending fails.
For now, I will make the following modification for this in the library:

(from line 587)    $this->CI->flexi_auth_model->set_error_message('activation_email_unsuccessful', 'config');
$this->delete_user($user_id); //ADDED KVG
return FALSE;

But if you agree we should stay in sync with this because I am reluctant to edit the library itself with regards to future updates... Smile

Regards, Klaas

One more important issue about inserting NULL values in the database.
I have a custom field in the Useraccount table 'user_type' which is an FK to a lookup table, but it is not required and therefore can be NULL.

Problem is that inserting NULL in the database raises an error, this seems to be related to the ActiveRecord library which escapes all values with backtics which is not accepted for NULL values.

I think this should be handled somewhere in the flexi_auth_model.update_user() function, but I want to share this with you first.

EDIT: An alternative would be, adding a value "not specofied" to the lookup table, thereby elimination the need for a NULL value. But I do not favour this solution, it should be possible to update a nullable field to the value of NULL>

The issue appears to be more general in nature and is described in this thread:

Though I still have no solution, escaping the values can be prevented by using the extra parameter on the $this->db->set method, but when using the field-value array approach, this does not work.
Even Phil Sturgeon commented the issue and consiferes it as a bug, but apparently it has not been solved yet.

I have found a solution by modifying the flexi-auth_model->update_user() method
It holds the assumption that a null value is passed in the post array as the string 'null', and does not add the quotes when a 'null' value is found. The update query code had to be rewritten for this:
In facyt the same goes for the insert, but in this case the lookup field can just be omitted in which case the database default value us used, which is also null.

(from line 315)
if (count($sql_update) > 0)  {
  //KVG:  handling null values correctly
  foreach ($sql_update as $field => $value) {
    if (strtolower($value) == 'null') {
      $this->db->set($field, $value, FALSE);
    } else {
      $this->db->set($field, $value);
  $this->db->where($this->auth->tbl_col_user_account['id'], $user_id);

Regards, Klaas

@Damiano Curreri

Since you say you can access the demo homepage, you have probably correctly setup the majority of the library and just have a minor error within one of your controllers.

I would double check that the 'base_url' and 'includes_dir' vars set in parent::__construct of each of your controller files is defined correctly.

$this->load->vars('base_url', 'http://localhost/your_codeigniter_directory/');
$this->load->vars('includes_dir', 'http://localhost/your_codeigniter_directory/includes/');

From the fact you say you can access the demo homepage which is loaded via the auth_lite controller, I'm presuming its the 'base_url' var set in this controller that is the problem.


You've been busy...

Regarding the insert_custom_user_data() function and the undefined $row_id var being returned, that's an obvious error that I've somehow missed...
Since potentially multiple row_id's could be set, I will likely have to overhaul the function a little to ensure it works well.

<b>Regarding your message on 28 September 2012</b>
You're right that the activate_user() function only returns a boolean value, this is what's in the user guide documentation, but the actual [email protected]' value within the model incorrectly states it's <i>void</i> - I'll update it.

As for the behaviour of how the demo handles the value returned by this function, I'm not too bothered about the current implementation as it's simply there as an example of using the function, it's really up to the developer to decide the function interactions within the site.

I think you may have deleted the parentheses from the uri_string() function sometime during your development as its in the current Github repo. Do a search for 'uri_string()' on https://github.com/haseydesign/flexi-aut...s/auth.php and you should see it there.

It's an interesting thought to include a database rollback transaction if the sending of the verification email fails.
I could probably implement the feature using CI's database transactions.

If you were to implement the transactions yourself to a stable level and were willing to share the code, I'd be more than happy to include it in the library with full credits where due.

As for your most recent message regarding NULL values in the database, I'll read into this later.

You've been sticking with the library for a while now, so are you liking it?

Thanks for your replies on these 3 issues!
Indeed issue 2 is a non-issue, probably I hit the delete key on a wrong moment...
Regarding issue one, thanks for updating.
And about issue three, I will think about that and will definately send you all code which I consider as an improvment or bugfix.

Furthermore, I have posted some extra info under the post about the NULL value issue, and also some code which, for now, addressed the issue.

So far I am impressed by the library, only the demo code is IMHO needlesly complicated and the extra "model" layer between controllers and library is not what I would prefer, but indeed this is in fact separate from the library.

I have to gain more experience with it, but I think it is very workable and the only alternative for IonAuth which lacks some functionality. Keep you informed!


I've just read your post and the Stack Overflow link regarding NULL values and CI's ActiveRecord library.

The fact that it's a CI bug causes problems, as CI could fix it with any update.
Whilst if I was to patch a work around like the code you have provided yourself into the library, I would have to go through every other function within the library to ensure it also patches CI's bug.

Patching the library would then mean I would have to go through and test that every function within the library still works as intended.

Since I'm short of spare time at the moment, I will add this to my watch list, and if other users are encountering the same problem, I'll have a look into implementing it.

Thanks for the code snippet.

[eluser]Jonny Blaze[/eluser]
First off -- thank you for this. I got it up and running super fast.

The one thing I've noticed is that Login Method always shows being logged in via password, even after closing the browser and reopening. I've tested in IE 10 and Chrome (22.0.1229.79 currently)

Hi haseydesign,
Thanks for nice library. I've been able to install and run it without any problems.
Everything went flawless. Thanks for the good documentation and demo too.

I'm now customizing demo instead of starting from scratch.
When I try to remove <span class="tooltip width_400">...</span> lines in login_view.php (to remove Example Users tooltip) I think Javascript causes a problem. Password field disappears when you navigate to E-Mail or username field.


[quote author="netty" date="1349378613"]Hi haseydesign,
Thanks for nice library. I've been able to install and run it without any problems.
Everything went flawless. Thanks for the good documentation and demo too.

I'm now customizing demo instead of starting from scratch.
When I try to remove <span class="tooltip width_400">...</span> lines in login_view.php (to remove Example Users tooltip) I think Javascript causes a problem. Password field disappears when you navigate to E-Mail or username field.


Use CSS code to hide such elements instead of removing them completely.

Hi Hasey,

I am still very enthousiastic about the lib and we surely are going to use ot for our website. There are nevertheless a couple of new issues:

When testing some custom dummy data with a bunch of users and custom tables, I encountered that the first user was not able to log in, the login screen just returned with an error message ('Your submitted login details are incorrect.') and empty fields.
The other users, with the same password, however could log in without any problem.

This first user had a userid of 0, which is legal in terms of a DB primary key. But indeed it was the culprit!
The call to flexi_auth_model->login(...) finally delegates to the function insert_database_login_session().
And this function starts with a test which fails:
if (!$user_id)
   return FALSE;

When a value of 0 is passed in, a legal primary key value so a legal $user_id value, it is interpreted as FALSE and therefore the function exits with FALSE and the login fails.

I think the test is not right, if tou just want to test whether a valid int value is passed in, a better test would be:
if (! is_int($user_id)) {
  return FALSE;

For now I choose to work with PK values starting with 1, but I think you get my point Smile

We noticed some strange behaviour when changing the login credential (in our case the email address). Is is not necessarily a bug but I just want to share it.
We are testing on different machines which makes the session management a bit unclear. Though it should be possible, especially in this time of mobile internet, to be logged in from different sources.
This appeared not to be a problem unless we changed the email address and clicked on the confirmation mail on the new address. The activation went fine but some data was lost.

The culprit was the call of the following function, which we copied from the demo application:
$this->data['user'] = $this->flexi_auth->get_user_by_identity_row_array();

Where this function normally returns the user data, it now returns am empty array
I have not dug very far in the code yet, but I think it just tries to lookup the user data by the old email address. It appears that after changing the call to

$this->data['user'] = $this->flexi_auth->get_user_by_id_row_array();

the right use data is returned, even after changing the email address and acces from still-alive session from some other machine.
I am just thinking about this, maybe I post more insights later.

I probably still miss something here but for now I wonder when the function get_user_by_identity() should be used, I think that this should merely be called by an administrator to access a given account.

Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  

Users browsing this thread:
2 Guest(s)

  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2017 MyBB Group.