I’m running Suse 10 and freepbx 2.1.3 and am able to log into the web UI if I turn authtype to ‘none’ in amportal.conf. Does anyone know how to fix this? I’ve seen some posts about apache2 not working with PHP5 session, but didn’t get enough information for a newbie to fix it
as I re-read this, I wasn’t too clear. I can’t use authentication with FreePBX and to get in, I have to turn Authenitcation=none. Since this won’t work in the long run, does anyone have ideas on how to get authentication from mysql to work?
I am also having problems getting this setting to work as described to provide database authentication for access to freePBX.
I am currently working with a Trixbox 2.0b2 / freePBX 2.2.0rc1 install that has been stable since this release was made available.
I have changed the AMPDBPASS parameter in amportal.conf and have made the change to the asteriskuser password in mysql. Everything works fine with the new password up until I make the change for AUTHTYPE=database in amportal.conf from AUTHTYPE=none. (I subsequently put the AMPDBPASS back to the default value just in case there was something unusual going one, but it does not seem to change the behaviour of the AUTHTYPE=database setting).
When I make this change and then attempt to access http://myTrixBoxIP, enter my credentials for admin acess and then attempt to access freePBX I am able to get to the welcome screen. From here, if I select “setup” or “tools”, etc… I am asked for additional creditials. I have read a few posts that refer to using admin / admin here, or admin / password, or even asteriskuser / my_asteriskuser_password and I have tried each of these without success. After entering a username and password I get no indication of any error, but neither am I able to access any of the freePBX functionality. Regardless of what freePBX function is selected, the browser goes into an endless wait state where is simply shows “waiting for my_server_IP” and firefox shows the “loading” status for the page. If I change the AUTHTYPE back to “none” while the browser is in this “waiting” state, the page will then finish loading the page without any further action on my part. I have also set AUTHTYPE=none and then gone into the setup/administrators screen and deleted the “admin” user (which is then removed from the ampusers table in mysql) as per one of the sugestions in another forum post, but nothing seems to produce the desired results.
Oddly enough, at one point when I was initially trying to get this working I was actually able to get through this database authentication. But, in trying to work through the process I must have made some change somewhere that broke it and now I cannot reproduce my earlier success. Everything still works fine without db auth…
Apparently, some underlying code is stuck in a loop trying some action that is non-fatal, but also non-terminating. If someone could point me to the code, I can likely put some debug statements there to determine where it is getting stuck. I have looked at config.php which appears to be the initial module called when a freePBX page such as “Setup” is accessed, but I was not able to see where the code would stall…
Any help would be appreciated. Thanks in advance!
OK look for the httpd.conf file
scan it and look for any folder security
it would say something like this
#Password protect /var/www/html/admin
AuthName "Restricted Area"
Require user wwwadmin maint
rem it out
now it in TB they would put it soem place non- standard
so do a search it it (them)
I am assuming that your post was for my benefit, and thanks for the quick response. Actually, I have already checked the httpd.conf file as per other posts here and on other forums. Apparently on this version of Trixbox / freePBX combo, they have already removed the lines from the file. The only remaining “Directory” contructs do not restrict based on user and are for other directories such as cgi-bin, etc…
As I indicated in my rather long post (sorry for that) when I have AUTHTYPE=database set, the freePBX pages (such as setup, etc…) will not load, the browser just goes into a waiting state forever. Changing AUTHTYPE back to “none” will almost immediatly cause the browser to proceed with the page load. So it would seem that somewhere in the underlying php code, things are caught in a loop waiting for something that never happens when trying to authenticate via mysql. I just have not been able to isolate where the hang is occuring (header_auth.php, header.php, functions.inc.php, etc…).
Any other thoughts?