Web Portal Login w/ MD5
Hello, I've been successfully using the web portal for quite a while and for the most part, it's been just fine. THE PROBLEMHowever, I've come up with a problem. Any time an account is created with the MD5 hash, e-mail and logging into e-mail directly works fine, but logging into the exim4u web portal does not so people are not able to manage their accounts via the web interface. It simply returns a login failed message. THE SETUPWhen I check the DB, the accounts that don't work have the MD5 with salt format such as: - $salt$hash- The DB field for crypt shows varchar(255) - The ones that do work I've had to manually reencrypt to non-MD5+salt. - I'm running v2.1.1 on Debian 7.8 (wheezy) - I also found some debug code in login.php, authuser.php and authsite.php but I can't figure out how to get that to display, I uncommented it and it's not showing up on the page. Any help or insight would be appreciated Thanks!
Hi Torry, 2015.03.07 21:46, Torry Crass wrote:
Hello,
I've been successfully using the web portal for quite a while and for the most part, it's been just fine.
THE PROBLEM However, I've come up with a problem. Any time an account is created with the MD5 hash, e-mail and logging into e-mail directly works fine, but logging into the exim4u web portal does not so people are not able to manage their accounts via the web interface. It simply returns a login failed message.
THE SETUP When I check the DB, the accounts that don't work have the MD5 with salt format such as:
- $salt$hash - The DB field for crypt shows varchar(255) - The ones that do work I've had to manually reencrypt to non-MD5+salt. - I'm running v2.1.1 on Debian 7.8 (wheezy) - I also found some debug code in login.php, authuser.php and authsite.php but I can't figure out how to get that to display, I uncommented it and it's not showing up on the page.
Any help or insight would be appreciated
Thanks!
I would guess that to view the debug output in login.php, you just have to uncomment that block and attempt to log in. My guess would be that perhaps your $cryptscheme is not set properly, or that perhaps that you are using some older version of Exim4U, which no longer works properly with new versions of PHP? Regards, Rimas
Thank you for the reply, I assumed as you did, that uncommenting it would display the debug code, having some PHP experience and all. But when I did uncomment it and then attempt the login, the debug code did not display. I even attempted to add in my own debug content with very basic echo statements where I found the "login=failed" entries in the code but none of those displayed either. Thinking that maybe I was just off my rocker and not looking in the right place I chmod 000'd the login.php file which successfully broke it, which tells me I was editing and looking through the correct files. I'm currently attempting to pull a new copy from github and set it up in parallel just to see if I can get around the problem with that. I think it's a bit odd that mail clients have no trouble authenticating, it's only the exim4u management interface... I'll share the results of my test with the new copy. Thanks! On Saturday, March 7, 2015 7:10 PM, Rimas Kudelis <rq(a)akl.lt> wrote: Hi Torry, 2015.03.07 21:46, Torry Crass wrote:
Hello,
I've been successfully using the web portal for quite a while and for the most part, it's been just fine.
THE PROBLEM However, I've come up with a problem. Any time an account is created with the MD5 hash, e-mail and logging into e-mail directly works fine, but logging into the exim4u web portal does not so people are not able to manage their accounts via the web interface. It simply returns a login failed message.
THE SETUP When I check the DB, the accounts that don't work have the MD5 with salt format such as:
- $salt$hash - The DB field for crypt shows varchar(255) - The ones that do work I've had to manually reencrypt to non-MD5+salt. - I'm running v2.1.1 on Debian 7.8 (wheezy) - I also found some debug code in login.php, authuser.php and authsite.php but I can't figure out how to get that to display, I uncommented it and it's not showing up on the page.
Any help or insight would be appreciated
Thanks!
I would guess that to view the debug output in login.php, you just have to uncomment that block and attempt to log in. My guess would be that perhaps your $cryptscheme is not set properly, or that perhaps that you are using some older version of Exim4U, which no longer works properly with new versions of PHP? Regards, Rimas _______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
Hi Torry, 2015.03.08 04:26, Torry Crass wrote:
Thank you for the reply,
I assumed as you did, that uncommenting it would display the debug code, having some PHP experience and all. But when I did uncomment it and then attempt the login, the debug code did not display. I even attempted to add in my own debug content with very basic echo statements where I found the "login=failed" entries in the code but none of those displayed either.
Thinking that maybe I was just off my rocker and not looking in the right place I chmod 000'd the login.php file which successfully broke it, which tells me I was editing and looking through the correct files.
OK, I just looked at the file again, and it's no longer as weird as it seemed. The thing is, these debug statements are there after FOUR die() statements. This just means that one of these preceding die() statements is being executed, so the debug output code is never reached. To actually get the debug output, you have to scatter them around. The following statements: print $_POST['localpart'] . "<br>\n"; print $_POST['domain'] . "<br>\n"; print "Posted crypt: " .$_POST['crypt'] . "<br>\n"; print $cryptscheme . "<br>\n"; print $cryptedpass . "<br>\n"; should go right after the include_once statements at the top. The following one: print $query. "<br>\n";; Should go above the '$result = ...' line. And the two remaining statements: print $row['localpart']. "<br>\n"; print $row['crypt'] . "<br>\n"; may stay where they are now.
I'm currently attempting to pull a new copy from github and set it up in parallel just to see if I can get around the problem with that.
I think it's a bit odd that mail clients have no trouble authenticating, it's only the exim4u management interface...
This just means that your password storage works. You see, mail clients authenticate against mail servers, meanwhile Exim4U management interface authenticates directly against the password stored in the database, and it obviously does that differently than the mail server. If Exim4U is misconfigured, as I suppose it is, your situation is not surprising.
I'll share the results of my test with the new copy.
Sure. Cheers! Rimas
Hi Torry, please have a look at my old post on this list from August 2014: http://exim4u.org/pipermail/users/2014-August/000226.html It may point you in the right direction. Regards, Michael Seidel Sysadmin FAI rent-a-jet AG http://www.fai.ag/ -----Ursprüngliche Nachricht----- Von: users [mailto:users-bounces(a)exim4u.org] Im Auftrag von Rimas Kudelis Gesendet: Sonntag, 8. März 2015 08:54 An: users(a)exim4u.org Betreff: Re: [Exim4U] Web Portal Login w/ MD5 Hi Torry, 2015.03.08 04:26, Torry Crass wrote:
Thank you for the reply,
I assumed as you did, that uncommenting it would display the debug code, having some PHP experience and all. But when I did uncomment it and then attempt the login, the debug code did not display. I even attempted to add in my own debug content with very basic echo statements where I found the "login=failed" entries in the code but none of those displayed either.
Thinking that maybe I was just off my rocker and not looking in the right place I chmod 000'd the login.php file which successfully broke it, which tells me I was editing and looking through the correct files.
OK, I just looked at the file again, and it's no longer as weird as it seemed. The thing is, these debug statements are there after FOUR die() statements. This just means that one of these preceding die() statements is being executed, so the debug output code is never reached. To actually get the debug output, you have to scatter them around. The following statements: print $_POST['localpart'] . "<br>\n"; print $_POST['domain'] . "<br>\n"; print "Posted crypt: " .$_POST['crypt'] . "<br>\n"; print $cryptscheme . "<br>\n"; print $cryptedpass . "<br>\n"; should go right after the include_once statements at the top. The following one: print $query. "<br>\n";; Should go above the '$result = ...' line. And the two remaining statements: print $row['localpart']. "<br>\n"; print $row['crypt'] . "<br>\n"; may stay where they are now.
I'm currently attempting to pull a new copy from github and set it up in parallel just to see if I can get around the problem with that.
I think it's a bit odd that mail clients have no trouble authenticating, it's only the exim4u management interface...
This just means that your password storage works. You see, mail clients authenticate against mail servers, meanwhile Exim4U management interface authenticates directly against the password stored in the database, and it obviously does that differently than the mail server. If Exim4U is misconfigured, as I suppose it is, your situation is not surprising.
I'll share the results of my test with the new copy.
Sure. Cheers! Rimas _______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
Michael, Your post is spot on to what the problem I'm running into is related to. Even in the newer source off of github that I was looking at it isn't resolved (and several other things are currently broken in that version, like no submit button on editing an existing account). -- though the old one does use MD5 passwords successfully. I've modified the function as you suggested but login is still not functioning properly, tossing a login failure to any SHA512 accounts. I'm still working on it but thought I would send a message thanking you for that guidance. On Sunday, March 8, 2015 5:00 AM, "Seidel, Michael" <michael.seidel(a)fai.ag> wrote: Hi Torry, please have a look at my old post on this list from August 2014: http://exim4u.org/pipermail/users/2014-August/000226.html It may point you in the right direction. Regards, Michael Seidel Sysadmin FAI rent-a-jet AG http://www.fai.ag/ -----Ursprüngliche Nachricht----- Von: users [mailto:users-bounces(a)exim4u.org] Im Auftrag von Rimas Kudelis Gesendet: Sonntag, 8. März 2015 08:54 An: users(a)exim4u.org Betreff: Re: [Exim4U] Web Portal Login w/ MD5 Hi Torry, 2015.03.08 04:26, Torry Crass wrote:
Thank you for the reply,
I assumed as you did, that uncommenting it would display the debug code, having some PHP experience and all. But when I did uncomment it and then attempt the login, the debug code did not display. I even attempted to add in my own debug content with very basic echo statements where I found the "login=failed" entries in the code but none of those displayed either.
Thinking that maybe I was just off my rocker and not looking in the right place I chmod 000'd the login.php file which successfully broke it, which tells me I was editing and looking through the correct files.
OK, I just looked at the file again, and it's no longer as weird as it seemed. The thing is, these debug statements are there after FOUR die() statements. This just means that one of these preceding die() statements is being executed, so the debug output code is never reached. To actually get the debug output, you have to scatter them around. The following statements: print $_POST['localpart'] . "<br>\n"; print $_POST['domain'] . "<br>\n"; print "Posted crypt: " .$_POST['crypt'] . "<br>\n"; print $cryptscheme . "<br>\n"; print $cryptedpass . "<br>\n"; should go right after the include_once statements at the top. The following one: print $query. "<br>\n";; Should go above the '$result = ...' line. And the two remaining statements: print $row['localpart']. "<br>\n"; print $row['crypt'] . "<br>\n"; may stay where they are now.
I'm currently attempting to pull a new copy from github and set it up in parallel just to see if I can get around the problem with that.
I think it's a bit odd that mail clients have no trouble authenticating, it's only the exim4u management interface...
This just means that your password storage works. You see, mail clients authenticate against mail servers, meanwhile Exim4U management interface authenticates directly against the password stored in the database, and it obviously does that differently than the mail server. If Exim4U is misconfigured, as I suppose it is, your situation is not surprising.
I'll share the results of my test with the new copy.
Sure. Cheers! Rimas _______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users _______________________________________________ users mailing list users(a)exim4u.org https://exim4u.org/mailman/listinfo/users
Hi, 2015.03.15 00:39, Gordon Dickens wrote:
On 03/08/2015 02:15 PM, Torry Crass wrote:
In the newer source off of github <snip> several other things are currently broken in that version, like no submit button on editing an existing account.
After some research I think that I have stumbled upon your problem. The recent github version uses imap_qprint which requires that you have php5-imap installed in debian. I just now discovered that if you don't have php5-imap installed then everything below the vacation message disappears including the submit button since the vacation message is displayed with imap_qprint. So install php5-imap and the broken pages and submit buttons should show back up with the github version.
It was actually my patch which added this possibility to use 8-bit characters in vacation messages. I think I chose to escape them using quoted-printable because Exim doesn't provide proper means to initialize a DB connection with a desired character set / collation properly, only workarounds exist to achieve that, and I wasn't aware of these workarounds back when I created this patch. If Exim added that option, it would be great. If not, perhaps one of these workarounds is a better option? Rimas
On 03/15/2015 09:43 AM, Rimas Kudelis wrote:
It was actually my patch which added this possibility to use 8-bit characters in vacation messages. I think I chose to escape them using quoted-printable because Exim doesn't provide proper means to initialize a DB connection with a desired character set / collation properly, only workarounds exist to achieve that, and I wasn't aware of these workarounds back when I created this patch.
If Exim added that option, it would be great. If not, perhaps one of these workarounds is a better option?
Hi Rimas, Yes, I realized that was your patch. Congratulations, you have done alot with Vexim over the past couple of years! As far as I understand, the exim developers intend for the 8-bit characters to be handled by workarounds, primarily in exim.conf, as you suggested. I agree that it would be best for exim to add better support for that feature. There are several bugs on the exim bugzilla site regarding this and similar issues, however, I haven't yet found a comprehensive solution proposal. You may want to consider posting a bug to the exim bugzilla site and see what their response is. I am personally not that up to speed on this issue and the workarounds so I am not quite sure what the best option is. Gordon
Hi Gordon, 2015.03.15 19:08, Gordon Dickens wrote:
Yes, I realized that was your patch. Congratulations, you have done alot with Vexim over the past couple of years!
Thanks! :) I just re-read my message, and it seems I sent it prematurely. I also wanted to say that the lack of IMAP functions in PHP should probably degrade in a more graceful manner. Perhaps I should write a patch for that?
As far as I understand, the exim developers intend for the 8-bit characters to be handled by workarounds, primarily in exim.conf, as you suggested.
What do you mean by "primarily in exim.conf"? The only workaround I remember off top of my head which involves exim.conf is to prefix all queries where 8-bit data is wanted with a SET NAMES statement, which appears rather ugly.
I agree that it would be best for exim to add better support for that feature. There are several bugs on the exim bugzilla site regarding this and similar issues, however, I haven't yet found a comprehensive solution proposal. You may want to consider posting a bug to the exim bugzilla site and see what their response is.
Apparently, I have already done that in 2010: http://bugs.exim.org/show_bug.cgi?id=980. It's kind of cool how I sometimes wonder if there is a bug filed about some problem that I've been having for quite some time with some product, and then I discover that there is a bug – the one I myself filed years ago. :) Rimas
On 03/07/2015 02:46 PM, Torry Crass wrote:
Any time an account is created with the MD5 hash, e-mail and logging into e-mail directly works fine, but logging into the exim4u web portal does not so people are not able to manage their accounts via the web interface. It simply returns a login failed message.
Then, on 03/08/2015 04:59 AM, Seidel, Michael wrote:
please have a look at my old post on this list from August 2014:
http://exim4u.org/pipermail/users/2014-August/000226.html It may point you in the right direction.
Hi Michael, Your suggested modifications to functions.php and variables.php work like a charm. Great job! I've added you mods to the github repo here: https://github.com/Exim4U/src/commit/0bad0642b60619c45ff84953920c1d8e76f2a43... Many thanks! Gordon
participants (4)
-
Gordon Dickens -
Rimas Kudelis -
Seidel, Michael -
Torry Crass