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@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@exim4u.org] Im Auftrag von Rimas Kudelis
Gesendet: Sonntag, 8. M��rz 2015 08:54
An: users@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'] . " \n";
print $_POST['domain'] . " \n";
print "Posted crypt: " .$_POST['crypt'] . " \n";
print $cryptscheme . " \n";
print $cryptedpass . " \n";

should go right after the include_once statements at the top. The following one:

print $query. " \n";;

Should go above the '$result = ...' line. And the two remaining statements:

print $row['localpart']. " \n";
print $row['crypt'] . " \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@exim4u.org
https://exim4u.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@exim4u.org
https://exim4u.org/mailman/listinfo/users