#284 Not able to add users in 1.4.10

[Anonymous]

I am using:

$auth["session"] = "host";
$auth["type"] = "db";

Host authentication takes in session uid from SAML - this works fine on every other part of version 1.4.10. Then authenticates based on uid=username on the database. I have this working perfectly with 1.4.09.

In version 1.4.10 edit_users.php I can add the first user and update that user except for its rights. When I try to add another user it goes through the entire process, with no php errors but never adds the user to db - again no errors. When I take the edit_users.php version 1.4.09 it allows me to add or edit new users based on perms... albeit with a lot of warnings because it looks like there were a lot of changes to the file in new version.

thanks
Dave

[Anonymous]

This is the mail system at host home.redux.org.uk.

THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Your message could not be delivered for more than 1 hour(s).
It will be retried until it is 5 day(s) old.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

               The mail system

jberanek@localhost.redux.org.uk (expanded from jberanek@localhost):
delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024:
Connection refused

[Anonymous]

This is the mail system at host home.redux.org.uk.

THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Your message could not be delivered for more than 1 hour(s).
It will be retried until it is 5 day(s) old.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

               The mail system

jberanek@localhost.redux.org.uk (expanded from jberanek@localhost):
delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024:
Connection refused

[Anonymous]

It seems that the whole form is not working at all. I can basically put anything into any field and it just moves on through doing nothing - example is password matching. Nothing saves to database even though it returns to the main screen - the main screen resolves fine. The only thing that I can do is edit whoever is logged in's email address... Again if I switch to 1.4.09 edit_users I get a bunch of "illegal string offset" warnings but it does allow for proper add and update of information based on the user's credentials.

[Anonymous]

The edit_users.php from the linked_bookings branch works. Not sure which one is newer but the 1.4.10 has an issue somewhere and not getting errors.

[Anonymous]

The 1.4.10 version is newer. The only difference between those two versions is that in 1.4.10 the database column names are quoted (`` in MySQL and "" in PostgreSQL) in the SQL query updating the database. Previously they hadn't been quoted because it was thought unnecessary due to the restrictions on the naming of custom fields. However using an SQL reserved word as a custom field name causes an SQL error unless you have the quoting.

Do you have some custom fields in your users table? If so, what are they called? And what database and version are you using? My guess is also that you are getting an SQL error in your error log.

Campbell

[Anonymous]

I originally had the custom field set up as uid (and then tried first_last) but I thought that may have been the issue too so took it out completely to test. Still had the issue.

MRBS 1.4.10
Database: MySQL 5.5.12
System: Windows NT NYCS02TWEB 5.2 build 3790 (Windows Server 2003 Enterprise Edition Service Pack 2) i586
Server time: 10/24/2013 11:36:49 AM
PHP: 5.4.16

[Campbell Morrison]

Very strange. I can't reproduce this at all. Could you do two things please:

(1) Let me know what your SQL mode is (run the query

SELECT @@GLOBAL.sql_mode;

in phpMyAdmin or similar)

(2) Uncomment the two debug lines at 746 and 747 in the 1.4.10 version of edit_users.php and let me know what the output is for a failing operation (obviously use some test data that you don't mind publishing)

Campbell

[Campbell Morrison]

One more thing to try. Just before the line

Header("Location: edit_users.php");

at line 529 in edit_users.php, please insert the lines

echo var_dump($level);
echo var_dump($min_user_editing_level);
echo var_dump($Id);
echo var_dump($my_id);
echo "Debug: not authorised";
exit;

Campbell

[Anonymous]

STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

OK. I added the 1.4.10 file back in and it works now. The only difference in the installation is that there is a lot of rooms and entries in the database now and I had added a few admins... I have a custom field in there and it works fine too. Uggg.

[Campbell Morrison]

My suspicion is that the version of edit_users.php that you are using is a red herring. If the quoting of the column name were a problem then you would be getting an error of some kind. My hunch is that what is happening is that you are falling foul of these lines, starting at line 525:

  // If you haven't got the rights to do this, then exit
  $my_id = sql_query1("SELECT id FROM $tbl_users WHERE name='".sql_escape($user)."' LIMIT 1");
  if (($level < $min_user_editing_level) && ($Id != $my_id ))
  {
    Header("Location: edit_users.php");
    exit;
  }

I think that in theory it shouldn't be possible to get there and it's just a precaution against someone trying to spoof the form input. However in your case I suspect that the problem is caused by the authentication method - not necessarily by the method itself, but that using that method exposes a flaw in the logic of the edit_users code.

If the problem does recur, as I suspect it may, then the debug output above would be useful.

Campbell