3rd party software access using XML-RPC for PHP
(http://phpxmlrpc.sourceforge.net/)
This particular connector I am "overseeing" the fine-tuning of, is working mostly correctly.
1) The connector was written for oscommerce and although it does not have any calls to osc functions, it is all direct db queries like
mysql_query("insert etc..
which for some reason makes me uneasy.
Is there any case (security/safety) to use the standard zen functions instead?
2) I would like the admin activity log to note when the connector does something.
Is there a function I could call to do that, or a dummy page it could load to trigger a log entry, or just easier to directly insert a record in the log?
Re: 3rd party software access using XML-RPC for PHP
If it were to call application_top properly then it would trigger the proper logging too.
Re: 3rd party software access using XML-RPC for PHP
Quote:
call application_top properly
Hmm... the "properly" bit is escaping me. Just including it crashes the application thats using it. The usual php error log is empty.
The structure of the file is like this
PHP Code:
include("xmlrpcutils/xmlrpc.inc");
include("xmlrpcutils/xmlrpcs.inc");
include("../../includes/configure.php");
//include("../../includes/application_top.php");//crashes application
define('RESPONSE_ENCODING', 'UTF-8'); //It must be your DDBB encoding
define('DEBUG_FILE', 'debug.xmlrpc.txt'); //Absolute path to debug and warning file
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
$con = mysql_pconnect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD);
mysql_select_db(DB_DATABASE);
followed by a list of the various functions, for example
PHP Code:
function get_taxes() {
debug('fn '.__FUNCTION__ . ' ('. __LINE__.', '.date('d/m/Y,H:i:s').')');//steve
$taxes = array();
$result = mysql_query("select tax_class_id, tax_class_title from tax_class;");
if ($result) while ($row = mysql_fetch_row($result)) {
$taxes[] = new xmlrpcval(array(new xmlrpcval($row[0], "int"), new xmlrpcval($row[1], "string")), "array");
}
return new xmlrpcresp( new xmlrpcval($taxes, "array"));
}
(Since this file is in a known location, I assume its vulnerable to cross-site scripting with the query as is?)
and at the end the creation of the new server object
PHP Code:
$server = new xmlrpc_server( array( "get_taxes" => array( "function" => "get_taxes",
"signature" => array( array($xmlrpcArray)
)
),
etc...
This issue is now more than a desire than just wanting access to be logged...the function that gets the payment methods chokes on paypalwpp as that payment method class references the base class and calls zen_functions which this file can't find, so I assume getting application_top called properly would solve that issue...
Re: 3rd party software access using XML-RPC for PHP
A couple things that stand out:
1. application_top should normally be loaded before configure.php ... because it will load configure.php automatically. So you won't need to call configure.php afterward either.
2. application_top expects that the file calling it is in a folder just ONE directory-level above it. Not two like you're doing. Use PHP's chdir() function to change directory into your ZC store's main folder before calling application_top.
Re: 3rd party software access using XML-RPC for PHP
Well, I could not get it to work with application_top.
I've done too many tests to detail it:
absolute paths,
chdir and reducing the path to configure.php (for testing that path combination that was ok),
moving the files to root
moving the files to includes.
But whatever I tried the best I could get was application_top not found irrespective of the path used (all combinations from absolute downwards), even when it could find configure.php with the same path.
While I can work round the actual problem that has instigated the desire to do this, its annoying to leave it at this.
FYI original path info, if that contradicts your previous post.
Shop
/home/xxxxx/public_html/tienda/includes/configure.php
Connector/calling file
/home/xxxxx/public_html/tienda/xyz/connector/connector_file.php
Wouldn't work at all with the file in the shop root...issue with the host code I think.
thanks anyway.
Re: 3rd party software access using XML-RPC for PHP
k,
so the file that remote services will call on your server is
connector_file.php
This should go in the root of the ADMIN directory,
then
in connector_file.php you have
PHP Code:
include('includes/application_top.php');
include(DIR_FS_ADMIN . 'somepath' . "xmlrpcutils/xmlrpc.inc");
include(DIR_FS_ADMIN . 'somepath' . "xmlrpcutils/xmlrpcs.inc");
define('RESPONSE_ENCODING', 'UTF-8'); //It must be your DDBB encoding
define('DEBUG_FILE', 'debug.xmlrpc.txt'); //Absolute path to debug and warning file
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
$con = mysql_pconnect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD);
mysql_select_db(DB_DATABASE);
note the 'somepath' bit will have to be adjusted to suit the location you have placed theses files.
e.g.
include(DIR_FS_ADMIN . 'includes/functions/' . "xmlrpcutils/xmlrpc.inc");
Re: 3rd party software access using XML-RPC for PHP
Hi,
I guess it should also be mentioned that by including the admin application_top.php you will also be restricted in that
it will attempt to 'authorise' any call to that file based on the existence (or not) of a valid admin_id in the current session
So in this sense it may not be suitable for you to include application_top.php
Re: 3rd party software access using XML-RPC for PHP
Thanks for the input.
I agree, that seemed the obvious way it should have been from the start...and one of the things I tried to begin with even before starting this thread but the host application wont connect with it in the shop root. I'm sure its a path discrepancy in the host code which I am trying to avoid fiddling with, my knowledge of Python is limited to dead parrots.
This is my problem with this issue, although I contracted a consultancy to deal with the host application and fix the (originally osc) connector, once I started testing I found all sorts of holes in it so have ended up revising the connector myself as its evident I can't trust anyone else to spend the hours required to test properly/be safe with poking about in my perfectly-functioning shop database.
So, back to vim...
