Undefined index: spam_drop when doing admin functions - adduser example.

[Matt Darcy]

Running vexim2 from master as of 16/08/2015 on a Centos 7 with Apache 2.4 and Maria DB mariadb-server-5.5.41-2

The install process is fine as normal, the database is a clean database created from the sql script at the time of the git clone.

when I try to add a user to a domain there is no error, the screen just refreshes back as it was before I add a user to a domain.

I am running the web server with a valid SSL certificate from a trusted third party.

in the http log vexim I see the following error when adding a user


[quote]
[Tue Aug 11 21:08:00.198830 2015] [:error] [pid 13713] [client 192.168.24.10:53208] PHP Notice:  Undefined index: spam_drop in /var/www/html/adm/mail/adminuseraddsubmit.php on line 141, referer: https://mailtest.local/adm/mail/adminuseradd.php
[/quote]


The code block in question is as follows - I've hilighted line 141

    $success = $sth->execute(array(':localpart'=>$_POST['localpart'],
        ':localpart'=>$_POST['localpart']
        ':username'=>$_POST['localpart'].'@'.$_SESSION['domain'],
        ':domain_id'=>$_SESSION['domain_id'],
        ':crypt'=>crypt_password($_POST['clear']),
        ':smtp'=>$smtphomepath,
        ':pop'=>$pophomepath,
        ':uid'=>$_POST['uid'],
        ':gid'=>$_POST['gid'],
        ':realname'=>$_POST['realname'],
        ':type'=>$_POST['type'],
        ':admin'=>$_POST['admin'],
        ':on_avscan'=>$_POST['on_avscan'],
        ':on_piped'=>$_POST['on_piped'],
        ':on_spamassassin'=>$_POST['on_spamassassin'],
        ':sa_tag'=>((isset($_POST['sa_tag'] )) ? $_POST['sa_tag']  : 0),
        ':sa_refuse'=>((isset($_POST['sa_refuse'] )) ? $_POST['sa_refuse']  : 0),
        ':spam_drop'=>$_POST['spam_drop'],
        ':maxmsgsize'=>$_POST['maxmsgsize'],
        ':enabled'=>$_POST['enabled'],
        ':quota'=>$_POST['quota'],
        ));


From my basic understanding of PHP (and it is basic) it this suggests that the form submitting does not have a valid index identifier for the field "spam_drop" when it's submitting it to eh web server.

Is anyone running a version of vexim with this code that works ? if so what's required to get this running ?

thanks,

Matt

[Rimas Kudelis]

Hi Matt,

you failed to mention whether or not the user was created, but I will
assume he wasn't.

Can you check out two things:
1. does the `users` table have a `spam_drop` field?
2. is there anything reported in maria's log?

The PHP error you pasted is definitely not a good thing, but it's a
notice only, so it shouldn't cause failure.

Rimas

> *':spam_drop'=>$_POST['spam_drop'],*

[Matt Darcy]

Hi Rimas,

sorry, I should have clarified, no the user does not get created.

the users table does have the spam_drop column.

+-----------------+-------------------------------------------------------------+------+-----+---------+----------------+
| Field           | Type                                                        | Null | Key | Default | Extra          |
+-----------------+-------------------------------------------------------------+------+-----+---------+----------------+

| spam_drop       | tinyint(1)                                                  | NO   |     | 0       |                |

+-----------------+-------------------------------------------------------------+------+-----+---------+----------------+

I've got the logging level up on Maria, even query logging.

I can see the query for the attempted insert, which looks sane.

                  117 Query     INSERT INTO users (localpart, username, domain_id, crypt,
      smtp, pop, uid, gid, realname, type, admin, on_avscan, on_piped,
      on_spamassassin, sa_tag, sa_refuse, spam_drop, maxmsgsize, enabled, quota)
      VALUES ('matt', 'ma...@testdomain.local, '3', 'CRYPTED_PASSWORD.', '/testdomain.local/matt/Maildir', '/testdomain.local/matt', '600', '600',

the other thing to mention, which I should have said well up front, is the database is called "prod_vexim" not just "vexim".

This doesn't seem to cause a problem looking at the SQL that is being run.

[Matt Darcy]

so it would appear that the spam_drop input box is having an impact on the SQL that is being inserted into the database

when I try to run the query details above, the insert fails, however it's failed because of the spam_drop column

ERROR 1048 (23000): Column 'spam_drop' cannot be null

I'm assuming because there is no index on the php form for spam_drop the value is not getting set in the SQL (hence NULL) and as the database column is "NOTNULL" it won't allow the insert.

[Rimas Kudelis]

Oh, I see.

Please pull from github, I've just commited a fix there (hopefully). :)

Rimas

[Matt Darcy]

I'll give this a try today, thank you

[Matt Darcy]

initial testing shows this is a good fix, basic tests seem fine, I'll check in more detail, but I think it works fine.

[Rimas Kudelis]

2015-08-21 16:39, Matt Darcy rašė:
> initial testing shows this is a good fix, basic tests seem fine, I'll
> check in more detail, but I think it works fine.

Great, thanks for the info!

Rimas