Repository navigation
Add setAuthorizer to Pdo\Sqlite #17321
Description
Activity
If I remember correctly, the only hurdle to also have this for PDO_Sqlite was indeed the lack of driver specific subclasses. Since that has changed, I think this is a reasonbable feature request. PR welcome!
For some context, I had a use case where setting the authorizer would be helpful in a package I maintain. For now I went with bundling compiled dll/so/dylib files with the composer package. This feature would simplify that a lot.
Also, one thing I was trying to do before resorting to bundling compiled libraries with my package was seeing if I could use FFI to achieve this. I'm not sure if this is something you'd want, but imo it'd be very helpful if
Pdo\Sqlitealso exposed thesqlite3*pointer asFFI\CData.Then you could just use FFI to do these things at the application level. libsqlite3 has pretty simple headers so I think it's a good fit for FFI.
One way to do this now is to load a SQLite extension which creates a function that returns the pointer as a u64, which then lets you do whatever you want using FFI, but the downside is you still need the actual compiled extension to create the function.
- linked a pull request that will close this issueImplement GH-17321: Add setAuthorizer to Pdo\Sqlite #17905
on Feb 23, 2025 What do you think about the suggestion above for getting a SQLite pointer for FFI purposes? If you think the suggestion is reasonable, should I open a separate issue for discussing that?
It's not something I'm a fan of as it encourages hacks. Normally we don't expose such internal pointers to PHP code.
Reacted by Christoph M. BeckerIt does feel a bit weird for PHP to expose a pointer, but at the same time with FFI being a thing, getting access to
sqlite3*seems fine (and I'd say it prevents other, more hacky approaches).It does feel a bit weird for PHP to expose a pointer, but at the same time with FFI being a thing, getting access to
sqlite3*seems fine (and I'd say it prevents other, more hacky approaches).The thing is that FFI is contained within its own thing, very much in the "you know what you're doing" territory. Exposing raw memory addresses to PHP can also be abused to mount an info leak attack in presence of a bug.
Is there anything else you'd like to access thesqlite*for? If so we should just add the functionality to pdo.Great work, thanks!
It seems to be missing all the constants though no?
Currently this is hard to use as the authorizer constants are only defined in SQLite3:
/* Constants for authorizer actions */ /** @cvalue SQLITE_CREATE_INDEX */ public const int CREATE_INDEX = UNKNOWN; /** @cvalue SQLITE_CREATE_TABLE */ public const int CREATE_TABLE = UNKNOWN; /** @cvalue SQLITE_CREATE_TEMP_INDEX */ public const int CREATE_TEMP_INDEX = UNKNOWN; …Could you add the authorizer constants to the PDO\SQLite class? Thanks :)
Description
Since we now have separate classes for different PDO types, could we get
Pdo\Sqlite::setAuthorizer()?The SQLite3 extension supports it: https://www.php.net/manual/en/sqlite3.setauthorizer.php
The C interface is pretty straightforward: https://www.sqlite.org/c3ref/set_authorizer.html, you get the action as an int, some string parameters, and return one of these values:
The SQLite3 extension's
setAuthorizer()has a bool return type so I'm assuming it'sSQLITE_OKandSQLITE_DENY, sinceSQLITE_IGNOREprobably has pretty niche use cases.