SQLSTATE[HY000]: General error when using jf::$RBAC->Permissions->Add('Test', 'Test Rights')

[giamteckchoon]

I am getting the following:

PHP Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error' in SNAP/PhpRbac/src/PhpRbac/core/lib/jf.php:61
Stack trace:
#0 SNAP/PhpRbac/src/PhpRbac/core/lib/jf.php(61): PDOStatement->fetchAll(2)
#1 [internal function]: jf::SQL_pdo('LOCK TABLE phpr...')
#2 SNAP/PhpRbac/src/PhpRbac/core/lib/jf.php(45): call_user_func_array('self::SQL_pdo', Array)
#3 SNAP/PhpRbac/src/PhpRbac/core/lib/nestedset/full.php(53): jf::SQL('LOCK TABLE phpr...')
#4 SNAP/PhpRbac/src/PhpRbac/core/lib/nestedset/full.php(419): FullNestedSet->Lock()
#5 SNAP/PhpRbac/src/PhpRbac/core/lib/rbac.php(74): FullNestedSet->insertChildData(Array, 'ID=?', 1)
#6 SNAP/test.php(32): BaseRbac->Add('Test', 'Test Rights')
#7 {main}

thrown in SNAP/PhpRbac/src/PhpRbac/core/lib/jf.php on line 61

In https://github.com/OWASP/rbac/blob/master/PhpRbac/src/PhpRbac/core/lib/jf.php#L61:

$res=$result->fetchAll ( PDO::FETCH_ASSOC );

I think we shouldn't use the above when there is an insert or update query?

[giamteckchoon]

I don't know whether is right or not, I replace the source from line 61 till line 64 with the following which solves the issue:

        $type = substr ( trim ( strtoupper ( $Query ) ), 0, 6 );
        if ($type == "SELECT") {
            $res=$result->fetchAll ( PDO::FETCH_ASSOC );
            if ($res===array())
                return null;
            return $res;
        } else {
            $res = self::$Db->lastInsertId ();
            if ($res == 0)
                return $result->rowCount ();
            return $res;
        }

Thanks in advance for taking time to look into this.

[jburns131]

Are you using PhpRbac v1.0 or v2.0 Beta?

If you are using v2.0 Beta you will need to use the new interface.

include 'PhpRbac/autoload.php';

$rbac = new Rbac();

$rbac->permissions->add('Test', 'Test Rights');

We still need to update the docs for v2.0 Beta, but for the most part you will use the above to instantiate the $rbac object and use $rbac rather than jf::RBAC.

Also, make sure you are using 'PhpRbac/database/database.config' for database configuration.

[giamteckchoon]

Thanks for taking time to response.

I am using v2-beta.

Actually I am trying not to use PhpRbac/database/database.config since my application already got one PDO link to MySQL and I don't feel comfortable to have two mysql database login information saved in file (one for phprbac and one in my application).

Currently I am doing:
require 'PATH/TO/PhpRbac/src/PhpRbac/core/lib/jf.php';
jf::setTablePrefix('phprbac_');
jf::$RBAC=new RBACManager();
jf::$Db = $DB;

Where $DB is the pdo_mysql link and I did commented out last 3 lines in jf.php:

//jf::setTablePrefix($table_prefix);
//jf::$RBAC=new RBACManager();
//require_once DIR."/../setup.php";

Or is there any way to go around this? Sorry, just trying phprbac and will try to find time to learn more from the sources.

Thanks again.

[jburns131]

I had a similar issue as you're describing in a project I'm working on. Here's the solution I use, and it works like a charm.

The database connection setting in my project are stored in constants.

I just updated my database.config with the following:

<?php

$host = DB_HOST;
$user = DB_USER;
$pass = DB_PASSWORD;

$adapter = "pdo_mysql";
$dbname = DB_NAME;
$table_prefix = DB_PREFIX;

Now I only have to keep track of one database config file. This is extremely handy in my project, as it's a CMS with an installation script where the user fills out a form with the db connection info and then the installer creates the dbConnections config, so every installation has different settings. But there's no need to worry about PhpRbac separately.

The above example should point you in the right direction, but if you need any help that's specific to your setup please let me know: jburns 131 at g mai l. c om... remove the spaces of course :-p

[giamteckchoon]

Thanks again.

For my case, I prefer not to use the database.config file at all. Personally I find it easier just to set jf::$Db and done with it :p I will try to learn more from the sources when I have the time.

Will email you whenever I have doubts.

Once again, thanks a lot for your kind responses ;)

[jburns131]

I'm not sure you will be able to do that with v2.0, especially the farther we move towards PSR compliance.

If you would like to interact directly with the jf class I'd suggest you use v1.0, as there won't be many changes in the future that would affect your customizations.

Maybe this is an issue that should be addressed in the code base, i.e. design a way that will ease the process of integrating PhpRbac into existing projects.

But because of the specialized nature of PhpRbac, and the advanced queries involved, there is no way to decouple the queries from the system, as the queries are the system.

My suggestion is to alter the database.config and let the rest of the system do it's job. Once the database.config has the proper values, there is no need, or reason, to customize the internals.

[jburns131]

Also, if you are using

require 'PATH/TO/PhpRbac/src/PhpRbac/core/lib/jf.php';

you are just hacking into the v1.0 code, which has been modified to work with the v2.0 wrapper class (Rbac.php). Yeah, if you want to do that, I definitely suggest you use v1.0.

[giamteckchoon]

Will look into the sources to learn more :p

Thanks again for your suggestion and advice ;)

[jburns131]

k, no problem at all :-)

[jburns131]

Setup Issue. Closing.

[giamteckchoon]

Sorry, just a note here in case someone reading this and encounter issue when using v2 beta on what you posted as below:

include 'PhpRbac/autoload.php';
$rbac = new Rbac();
$rbac->permissions->add('Test', 'Test Rights');

The above didn't work for me. However, changing:

$rbac = new Rbac();

To

$rbac = new PhpRbac\Rbac();

Works.

Thanks.

[abiusx]

I think it is supposed to be the second way, unless you do:
use PhpRbac;

This is for PSR-Compliance (the whole purpose of version 2).
-Abbas

---

Notice: This message is digitally signed, its source and integrity are verifiable.
If you mail client does not support S/MIME verification, it will display a file (smime.p7s), which includes the X.509 certificate and the signature body. Read more at Certified E-Mail with Comodo and Thunderbird in AbiusX.com

On Oct 7, 2013, at 9:00 AM, Giam Teck Choon notifications@github.com wrote:

Sorry, just a note here in case someone reading this and encounter issue when using v2 beta on what you posted as below:

include 'PhpRbac/autoload.php';
$rbac = new Rbac();
$rbac->permissions->add('Test', 'Test Rights');

The above didn't work for me. However, changing:

$rbac = new Rbac();

To

$rbac = new PhpRbac\Rbac();

Works.

Thanks.

—
Reply to this email directly or view it on GitHub.

[giamteckchoon]

Thanks Abbas. In the end, I do as per Jesse's suggestion and use constants in database.config file.

Once again, thanks to both of your prompt responses ;)

[jburns131]

Here are some examples.

If you are using an autoloader point it to 'PhpRbac/src'.

If you are not using an autoloader then include 'PhpRbac/autoload.php'.

One you have autoloaded/included the project, you have the following options to instantiate an object.

With a 'use' statement:

use PhpRbac;

$rbac = new Rbac();

Without a 'use' statement, outside of a namespace -

$rbac = new PhpRbac\Rbac();

Without a 'use' statement, inside of another namespace (notice the leading backslash) -

$rbac = new \PhpRbac\Rbac();

Hope this helps.