-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
$rbac->reset() does not set up correct links with root due to auto increment settings #37
Comments
Hello, and I apologize for the delay in a response. I have a few questions:
All ID, Lft and Rght columns should have the database type of 'int(11)'. I don't know how those columns could contain alphabetical characters if the columns are integers. If those columns are of the type 'int(11)' then there is a possibility the method used to query the above results is returning 'x' or 'y' for some reason. If you look at the file 'PhpRbac/database/mysql.sql' you can see what the proper structure of the database tables should be. Warning, the following is my personal opinion only. I don't think it has anything to do with this issue, although it might be good to look into the mysqli API to see if there is reason it would return the values 'x' or 'y'.* My recommendation is to use the 'pdo_mysql' adapter. Here is a comparison of the three MySQL API's (PDO, MySQLi, MySQL): https://php.net/manual/en/mysqlinfo.api.choosing.php As you can see the syntax is similar. The PDO interface is strictly OO. PDO supports all MySQL 5.1+ functionality. PDO better supports Multiple Statements, and PHP-RBAC uses Multiple Statements in a few complicated queries. And it's my opinion that it is a little more future-proof and easier to adapt if you (or we) want to support multiple database systems. I also think PHP itself is investing in PDO as the future of database connection abstraction. |
I thought it was clear, but I am not getting actual letters returned. I wrote X and Y to signify that the values are variable, depending on the last auto-increment integer of the table. i.e. if I add 10 permissions to the database, and then call $rbac->reset(), Y would be equal to 12 (i.e. the next auto increment value). I have been working directly with the db tables a lot, and I really could have messed something up, but I only got this issue directly after upgrading to 2.0.0. |
It seems like a valid bug. Notice: This message is digitally signed, its source and integrity are verifiable. On Apr 16, 2014, at 1:55 AM, Aleksander notifications@github.com wrote:
|
Sorry, I'm either a space shot, or very specific (read anal-retentive lol). A unit test and/or code snippet, along with steps to reproduce would be great. In the mean time I'll try to reproduce locally. |
I most definetely have been fiddling directly with single db entries, so this could still very much be a user error. Even if so, I would think that the reset() function should be altered to indeed be a full reset, not just a "soft" reset. I will try to cook something up to reproduce. |
Dropping tables and creating them again is not convenient, it is very slow, requires a lot of DBMS activity, and is the lazy way of truncating the data and resetting metadata. Notice: This message is digitally signed, its source and integrity are verifiable. On Apr 16, 2014, at 2:30 AM, Aleksander notifications@github.com wrote:
|
I found the error, and it's on my part. Apologies for taking up your time. When reading through the source code I noticed the ALTER TABLE statement, and I realised that somewhere along the line I have removed permissions for my db user to do ALTER. This would of course not enable the auto_increment reset, and thus cause all my issues. Issue can be closed. Again, sorry for the noise 👎 |
Still its something we didn’t think of, and somebody might face it later. Lets keep this thread for that. Notice: This message is digitally signed, its source and integrity are verifiable. On Apr 16, 2014, at 2:48 AM, Aleksander notifications@github.com wrote:
|
No worries on that. It's usually the misplaced comma that messes us up, because we're too busy looking for big logical errors :-) |
After going through this myself I looked this up and its normal behaviour i think, I run the command from the mysql shell and all seems to be going ok, After some searching it seems that in the manual for MySQL some more information is found. http://dev.mysql.com/doc/refman/5.7/en/alter-table.html
|
Hi All, I am new to using phpRBAC. However I have been successful in using it. As I am using mssql and the example has just sqllite. I manually created the db and imported the library but when I run the program it gives me this error Warning: mysqli::prepare() [mysqli.prepare]: Couldn't fetch mysqli in C:\xampp\htdocs\TenderSystem\template_contentII\DEVELOPER\PHP_version\PHP_HTML_Version\PhpRbac\src\PhpRbac\core\lib\Jf.php on line 148 Warning: Jf::sqlMysqli() [jf.sqlmysqli]: Couldn't fetch mysqli in C:\xampp\htdocs\TenderSystem\template_contentII\DEVELOPER\PHP_version\PHP_HTML_Version\PhpRbac\src\PhpRbac\core\lib\Jf.php on line 149 Notice: Unable to prepare statement: SELECT ID AS ID FROM phprbac_roles WHERE Title=? LIMIT 1, reason: in C:\xampp\htdocs\TenderSystem\template_contentII\DEVELOPER\PHP_version\PHP_HTML_Version\PhpRbac\src\PhpRbac\core\lib\Jf.php on line 149 Warning: call_user_func_array() expects parameter 1 to be a valid callback, first array member is not a valid class name or object in C:\xampp\htdocs\TenderSystem\template_contentII\DEVELOPER\PHP_version\PHP_HTML_Version\PhpRbac\src\PhpRbac\core\lib\Jf.php on line 159 Fatal error: Call to a member function execute() on a non-object in C:\xampp\htdocs\TenderSystem\template_contentII\DEVELOPER\PHP_version\PHP_HTML_Version\PhpRbac\src\PhpRbac\core\lib\Jf.php on line 160 Can you please point me to the right direction. Thanks. |
Just to be clear, have you been succesful or unsuccesful, and are you using MS SQL or MySQL?
|
I am using MS SQL. |
(I could have some issues with my database so I need someone else to confirm this)
After running $rbac->reset() I get the following in my mysqli database as default values:
rolepermissions.RoleID = 1,
rolepermissions.PermissionID = 1
permissions.ID = y
roles.ID = x
userroles.RoleID = x
The auto increment number for Permissions.ID and Roles.ID are not reset to 1, the link between the Permissions and Roles in the rolepermissions table is therefore broken. X and Y should be equal to 1.
Seems not to cause any issue in the userroles table as this link is kept.
I suppose an easy fix would be to also reset the auto increment value, or to drop the table and recreate it completely. The former could have unforseen impacts on custom implementations of your library.
Edit: I am using v2.0.0 release
The text was updated successfully, but these errors were encountered: