Banshee, the secure PHP framework

Forum

Not able to login to banshee CMS

Ady
10 April 2016, 11:43
Hi all,
I am not able to login to banshee cms, it says incorrect password. I have manually imported mysql db. Here is my config file
# Database settings
#
DB_HOSTNAME = localhost
DB_DATABASE = banshee
DB_USERNAME = root
DB_PASSWORD = password

when i do localhost/setup, it says login with admin and password as banshee, However that does not work. Let me know what i m missing..
Hugo Leisink
10 April 2016, 19:45
I don't know. Username is 'admin' and password is 'banshee'. It should work...
Kapageridis Stavros
12 April 2016, 13:31
Check your DB config and see if there is 127.0.0.1 instead of localhost.
chapchap70
25 June 2017, 07:20
I have a similar situation as this old thread but have more info.

I put a newer second instance of Banshee on this machine (6.0) but had to upload the database manually due to the following error... "The MySQL command line client is missing. Install it and refresh this page." I have this installed so I am assuming Banshee is looking for it in a different location.

I compared the two "users" tables and found that the password field of the new nonworking cms contains "none" while the working one is a long string. Below is the contents of the table of the 6.0 users table that I am unable to log into the cms. I tried leaving the password blank, and trying to add an 8 character password into the table and matching it while logging in. (didn't think that would work but tried anyway)

ID=1 organization_id=1 username=admin password=none one_time_key=NULL cert_serial=NULL status=2 authenticator_secret=NULL fullname=Administrator
Hugo Leisink
25 June 2017, 22:12
Use the script 'database/set_password' to reset the password of you account.
chapchap70
26 June 2017, 02:36
Thanks! That worked.
Brian Tiffin
1 July 2017, 01:11
Just a note Hugo,

Regarding default Banshee accounts, the mysql.sql in settings/ has
--
-- Dumping data for table `users`
--

LOCK TABLES `users` WRITE;
/*!40000 ALTER TABLE `users` DISABLE KEYS */;
INSERT INTO `users` VALUES (1,1,'admin','none',NULL,NULL,2,NULL,'Administrator','root@localhost');
/*!40000 ALTER TABLE `users` ENABLE KEYS */;
UNLOCK TABLES;

It sets an invalid "admin" password and does not create user "user" during initial setups. At lines 1070-1078.

The database/set_password hint was a saving grace on getting a trial setup working, but end users still need to add "user" by hand if they want to match the current docs given the current banshee-6.0.tar.gz file.

Awesome work by the way, Hugo. Banshee is in the lead running for a community site build for the GnuCOBOL project. Hiawatha is already the first choice of server.
Brian Tiffin
1 July 2017, 11:14
Another note,

During init and first visit to Banshee, in model/setup.php, exec("which mysql") seems to fail here, which causes the next step to assume there is no mysql_client. Fedora 24, custom source build of PHP 7, but not much else other than stock installs.

For example

trial.php
<?php
echo "which mysql" . "<br/>" . PHP_EOL;
exec("which mysql", $output, $result);
echo "Result: " . $result . "<br/>" . PHP_EOL;
echo "Output: <pre>"; var_dump($output); echo "</pre>" . "<br/>" . PHP_EOL;

//if ($result != 0) {
// return "mysql_client";
//}

echo "type mysql" . "<br/>" . PHP_EOL;
exec("type mysql", $output, $result);
echo "Result: " . $result . "<br/>" . PHP_EOL;
echo "Output: <pre>"; var_dump($output); echo "</pre>" . "<br/>" . PHP_EOL;

echo "command -v mysql" . "<br/>" . PHP_EOL;
exec("command -v mysql", $output, $result);
echo "Result: " . $result . "<br/>" . PHP_EOL;
echo "Output: <pre>"; var_dump($output); echo "</pre>" . "<br/>" . PHP_EOL;

phpinfo();

echo "PATH: " . getenv("PATH", false) . "<br/>" . PHP_EOL;
exec("set", $output, $result);
echo "Result: " . $result . "<br/>" . PHP_EOL;
echo "Output: <pre>"; print_r($output) . "<pre>" . "<br/>" . PHP_EOL;
?>

Output of that, from a default home site setup (with a source build of PHP 7, so the hiawatha.conf direct .php to /usr/local/bin/php) and only including the text before the php_info dump by browsing to localhost:port/trial.php:

which mysql
Result: 1
Output:

array(0) {
}


type mysql
Result: 0
Output:

array(1) {
[0]=>
string(23) "mysql is /usr/bin/mysql"
}


command -v mysql
Result: 0
Output:

array(2) {
[0]=>
string(23) "mysql is /usr/bin/mysql"
[1]=>
string(14) "/usr/bin/mysql"
}

Changing models/setup.php to use "type mysql" instead of "which mysql" allows the rest of the setup to continue.

Cheers
Hugo Leisink
1 July 2017, 12:48
Thanks for the feedback. I will look at your comments and use them for the next release. Please, let me know what choice was made for the GnuCOBOL website.
Brian Tiffin
1 July 2017, 17:34
Root cause of the which command failing is lack of PATH in the CGI environment. It turns out it can be fixed with Setenv PATH = ... in hiawatha.conf (though the implications of that will need study). Otherwise it needs to be a full path in the models/setup.php exec command, and suffer the whims of shell internal commands and platform issues.

Still looking at Banshee for the site, but need to figure out how to do a few basic things with the engine, Hugo. Things like placement of Login/Logout menu items/buttons, preview of BBCode in the Forum and message edits. Will keep you informed of the progress. Nice look and feel and a highly readable codebase. Just have to read through it now before planning too many customizations. Kudos once again.
chapchap70
2 July 2017, 02:44
I uncommented the "setup" line in public_modules.conf, set my DEBUG_MODE to yes, renamed my 6.0 database, and ran a fresh setup. I can confirm that changing line 13 of /models/setup.php from ..."which mysql" to ... "type mysql" made it possible for me to complete the initial setup and creation of the new banshee database without errors.

Another note; lines 13-16 were not in version 5.4. I built PHP 7.1.0 from source and my Linux distro which runs the server is FatDog 710.
chapchap70
2 July 2017, 03:09
Well, what I said wasn't quite true; I got a 500 Internal Server Error as the database finished uploading. Entering the website.com/setup url again (not refreshing) took me to the banshee setup phase and the database seemed to upload correctly. I am using Hiawatha 10.4 and the internal server error cause is quite possibly something I did wrong.
chapchap70
2 July 2017, 03:48
TimeForCGI = 30 in my VirtualHost got rid of the 500 error. Didn't check what the default is but was getting the 500 error after about 7 seconds. The upload seemed to take about 15 seconds without error after I changed the TimeForCGI.
Hugo Leisink
3 July 2017, 07:54
Every step in Banshee's setup procedure should not take that long.