Putting the query in SQL action 1 on ACTIVATION (WARNING: use only integer substitutions), etc.. instead of calling a procedure.

krileon, the procedure call is an SQL query. As I just said, you could execute this line using the SQL tab in phpMyAdmin.

I'm using a procedure because the integration is imposible otherwise. There are multiple queries plus some logic inside those procedures.

I'll try to execute a simple query and change something in the joomla database in order to discard the possibility of the SQL plugin not working at all.

Do you filter/discard the input before executing the queries of this plugin ?, because this would explain everything if you didn't expect procedure calls.

Post edited by: amazeika, at: 2009/07/10 22:32

krileon, Thank you for this info,

I'll take a look at cb.database.php tomorrow and let you know about the result of some tests I'm planning to perform tomorrow.

but at this point it's undecided to allow unsecured queries as that's a major security risk

This is just not possible, you allow the execution of queries or you don't, there is no way to know if a query is insecure, I mean, you can filter the input variables, then escape the output, but thats it.

Best regards

Well I have good news ,

I started making simple tests (some simple rows insertion within the same DB ) to actually see if the plugin was working. After this I tried will a very simple stored procedure, which was also successful.

The next step was to try the same procedures over the PhpBB DB. ALSO A SUCCESS !!!, at this point I told to myself, DAMM how is this possible, since the integration procedures actually work when I execute them from the console.

It occurred to me to take out two selects that I wrote for debug purposes. They served as print statements in order to see the value of some variables while the procedures where being executed. After I removed them BAM, it worked, I was amazed and confused, but HAPPY . It would say that when Joomla sees some output given from MySQL, the execution is actually interrupted, so I performed a last test:

This works when calling it with CALL testProc('A test')

[code:1]CREATE PROCEDURE `testProc`(val VARCHAR(32))
BEGIN
INSERT INTO cbsubs_plg_test VALUES (null,val);
END[/code:1]

and this one doesn't when performing the same call

[code:1]CREATE PROCEDURE `testProc`(val VARCHAR(32))
BEGIN
SELECT val;
INSERT INTO cbsubs_plg_test VALUES (null,val);
END[/code:1]

The difference is the SELECT val statement that actually prints the value.

Crazy isn't it ?.

The important thing, is that the problem is worked out and that you guys already know that stored procedures actually work with CBSubs.

I will prepare a post showing how to integrate PhpBB with CBSubs in order to grant/deny access to PhpBB groups upon subscription/expiration. This is actually a great feature that will add a lot of value to CBSubs .

Arunas