[PHP] PHP equivalent for Oracle ORA_FFI
We have a data load program written in Oracle Reports 2.5 (yes, I know, it
wasn't me!). This uses ORA_FFI to interface with a .dll to validate and
reformat addresses. I would like to perform the same interface in PHP if
possible, without needing to do any development work on or around the .dll.
Can anyone point me in the right direction?
Some sample code below. The key points are, I think.
1. Oracle seems to be able, using Ora_FFI, to directly access a function in
a .dll, passing it parameters, and receiving its return output.
2. In the package initialization, at the end of the page, the .dll
'TBIF100.dll', referrred to as a library, is first loaded and opened, and
then the function 'PAS988V659' within the library is registered along with
its in/out parameters.
3. As a result of this, the dll and the function are assigned handles. The
function handle is used in the function i_obm988 to actually execute the
function.It's a rather strange looking bit of PL/SQL but it works!
PACKAGE BODY call_cbm988_pas IS
lh_obm988 ora_ffi.libHandleType;
fh_obm988 ora_ffi.funcHandleType;
FUNCTION i_obm988(
funcHandle IN ora_ffi.funcHandleType
,cons_name IN OUT VARCHAR2
-- other parameters
)
RETURN PLS_INTEGER;
PRAGMA INTERFACE(C,i_obm988,11265);
BEGIN -- Package Initialization
BEGIN
lh_obm988 := ora_ffi.find_library('TBIF100.dll');
EXCEPTION WHEN ora_ffi.FFI_ERROR THEN
lh_obm988 := ora_ffi.load_library(NULL,'TBIF100.dll');
END ;
fh_obm988 :=
ora_ffi.register_function(lh_obm988,'PAS988V659',ora_ffi.PASCAL_STD);
ora_ffi.register_parameter(fh_obm988,ORA_FFI.C_CHAR_PTR);
ora_ffi.register_parameter(fh_obm988,ORA_FFI.C_CHAR_PTR);
-- register other parameters
END call_cbm988_pas;
Thanks
Euan
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] OCIExecute hangs with invalid sql statement
The following code works fine if passed a valid sql statement in $sql, but if not it hangs. $this-conn=OCIPLogon($orauser,$orapwd,$tns) or die (Could not log on to database); $this-stmnt = OCIParse($this-conn, $sql) or die (Could not initialize database query (parse)); $result = OCIExecute($this-stmnt) or die (Could not perform database query (exec)); I have tried to identify an error at the OCIParse stage, using OCIError, but without success. It seems OCIParse does not return or generate an error for an invalid statement. Instead it returns a statement ID which apparently sends OCIExecute into a coma. Any ideas? Thanks Euan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Wierd error messages
Today my php 4/Apache/NT 4/Oracle 8i setup has started misbehaving. First sign was a huge slowing down in the delivery of pages. Then Apache crashed. I couldn't find anything interesting in the apache error log, but in the php error log there are hundreds of messages like the ones below. Can anyone explain, suggest how to deal with them? I should say that I have rebooted both of the database and web servers. TIA Euan [25-Apr-2001 14:34:48] PHP Warning: Missing ] in üu variable in Unknown on line 0 [25-Apr-2001 14:34:50] PHP Warning: Missing ] in }´üt variable in Unknown on line 0 [25-Apr-2001 14:34:50] PHP Warning: Missing ] in üu variable in Unknown on line 0 [25-Apr-2001 14:34:50] PHP Warning: Missing ] in }´üt variable in Unknown on line 0 [25-Apr-2001 14:34:50] PHP Warning: Missing ] in üu variable in Unknown on line 0 [25-Apr-2001 14:50:47] PHP Warning: Missing ] in variable in Unknown on line 0 [25-Apr-2001 14:50:50] PHP Warning: Missing ] in variable in Unknown on line 0 [25-Apr-2001 14:50:50] PHP Warning: Missing ] in variable in Unknown on line 0 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Why is it dangerous to have register_globals on?
Now I understand! I hadn't twigged to the danger of _internal_ variables
getting overwritten by bogus get/post variables.
Thanks to you all.
Euan
Rasmus Lerdorf [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Actually it's not dangerous per se.
However if can be very dangerous if you aren't being careful in your
code,
for instance, consider this.
Let's say I've conditionally set $sql somewhere else in the code based
upon
certain conditions, which works fine. But let's say those conditions
aren't
met so $sql doesn't get set to anything since it's not really used. Now
consider this code:
if ($sql)
{
$result = mysql_query($sql);
}
Now that would be fine for all normal instances. But now what if someone
appends this onto the end of your url:
?query=
...plus something like DROP databasename. It doesn't take too much
imagination to see what kind of things could happen if someone just had
a
little bit of knowledge about how your code works.
Thus you have two options. One is of course to turn register_globals
off,
but ALWAYS ALWAYS _ALWAYS_ set a default for every variable you refer to
in
your script at some point before doing anything with it. So if you use
$sql
be 100% sure that it has been set $sql explicitly in your code before
doing
anything with it.
Whether you turn register_globals off or not, you need to always watch
cases like this. I have seen many people say that register_globals is
inherently insecure and then they turn it off and go through and use
something like $HTTP_POST_VARS['sql'] everywhere they used to use $sql.
This only makes it slightly more tedious to inject bogus variables into
since the attacker now needs to make a trivial little form to inject stuff
into the POST data instead of just sticking it onto the URL.
Security-wise there is no difference whatsoever.
Never never never trust user-supplied data implicitly. Always check
anything that could possibly come from the user. For internal variables,
always initialize them and just generally think things through as you
write your scripts. This is no different in PHP than in any other
scripting language used for web work.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
