Re: [PHP-DEV] register_globals vs session.force_nocookie
Jani Taskinen wrote: I was wondering (I'm propably wrong, it's almost 6am here :) that wouldn't the real fix for this without having to add yet-another-ini-option have been to fix this so that logic with session.use_cookies and session_use_trans_sid worked like it was (?) meant to work. I agree. That should be the same. But what about use_cookie=1 and use_trans_sid=1 situation? When should we allow to fallback from cookie to URL propagation? Shouldn't the GPC rule apply here too? I know the problem with the very first hit, when we know nothing of cookies enabled or not.. But the session offered in the url is checked and eventually created, before the firts redirect/cookie_check. SO at this point, before the initial redirect, we know if this is a 'living' or a 'newborn' session. I wonder if, even at the application level, it would make sense to trigger this with the canges in the propagation mode, and block any downgrade in propagation mode. But I slept only a few hours too. It is unusual that the same client would switch cookies on/off amid the way, and if this happens we are probably facing a client qui pro quo. Once the client has proven to be cookie-enabled, why should we accept a lower level, if we don't expressly want it (use cookies if they are enabled). I know counting on the possibility to force a downgrade in the propagation mode is a very common practice of writing code, but we should be able to do the same with a little bit more of control. So these directive should be overridable on a per script basis. Giancarlo ie. session.use_cookies=1 and session_use_trans_sid=0 would not use any other session id but the one provided by the cookie? btw. Cookies can be forged too.. --Jani On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote: Hi. Last here, same period, I found that nasty thing in ?_PHPLIB[libdir]=http:// It was the nefarious start of the register_globals=off saga. Now Sascha has agreed to add a session.use_only_cookie directive, because session.use_cookie wasn't doing it really all the times. In fact, contrary to what advertised, session.use_cookie doesn't uses cookies if a SID is found in the URL, and can so be forced to use a user_provided variable when it should not. The winning argument, for the new session.use_only_cookies, has been that, with the actual settings, there cannot exist a situation in which PHP would discard the ID in the URL, and go cookie_or_nothing, as the banks do. It is forceable. Even if the client has cookies enabled. You know, really secure sites use *only cookies* propagation, or you don't do your home banking. Because cookies are the closest thing that can assure that we are speaking to the same client, that noone can takeover a session. The basis for this behavior of session.use_cookie is that we may not know when coookies are enabled, not on the very first hit, when I suppose a redirect to self is made and the cookie is then checked for presence. The aim to use cookies, if available, is because cookie is an acronym of 'not transferrable among clients that support cookies', that is it goes as close as possible to identify a single client. My interpretation of session.use_cookie is: if cookies are enabled, try to use them as a propagation because they cannot be transferred among clients (see the acronym above). If this is the aim, and on coming back from the redirect we found a cookie, still the presence of a user-provided SID in the url should make us suspicious. If we want to prevent session takeovers, here we are in presence of a transfer. We couldn't know that cookies were enabled the very first hit, but now we know it, and there is a SID in the URL... someone is forcing a transfer. Discard the sid and issue a new cookie. Once we know cookies are enabled we should stick to them, not because they are a better way of storage, but because tey guarantee uniqness of the client. So why should we allow a transfer from outside? All this is apart from other concerns, as the possibility to create session_id at will, with pleasing and easy-to-remember values, to be offered around for those 'social engineering' attacks, with no hope for the poor cookie-enabled victim to avoid it. Isn't his similar to the register_globals=on problem, where untrusted user provided values can make their way inside the script? Isn't this variable even more important, to let it in? Giancarlo Pinerolo -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3.0-dev-zend2-alpha segfaulting
Hi,
Thanks for the good bug report. I have fixed this problem in the CVS.
Andi
At 12:39 PM 6/14/2002 +0200, Hakan Kuecuekyilmaz wrote:
Hi,
following script segfaults at
in doubleloop 10/22
Segmentation fault
?php
class benchmark
{
var $index;
function benchmark($num)
{
for ($i = 0; $i $num; $i++) {
$this-index = $i;
}
}
}
for ($i = 0; $i 100; $i++) {
for ($j = 0; $j 100; $j++) {
$arr[$i][$j] = new benchmark(100);
echo in doubleloop . $i . / . $j . \n;
}
}
?
with php 4.2.1 everything is fine
here is a bt:
#0 0x7059c7e8 in realloc () from /lib/libc.so.6
#1 0x7059c758 in realloc () from /lib/libc.so.6
#2 0x001940ac in _erealloc (ptr=0x313dd8, size=40960, allow_failure=0,
__zend_filename=0x21ba50
/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_objects_API.c,
__zend_lineno=51, __zend_orig_filename=0x0, __zend_orig_lineno=0)
at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_alloc.c:298
#3 0x001c5254 in zend_objects_store_put (object=0x3a7c00,
dtor=0x1c4440 zend_objects_destroy_object, clone=0)
at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_objects_API.c:51
#4 0x001c3f5c in zend_objects_new (object=0xefffdcc0,
class_type=0x320ce8)
at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_objects.c:58
#5 0x001b3aa0 in _object_and_properties_init (arg=0x3a7560,
class_type=0x320ce8, properties=0x0,
__zend_filename=0x21bc10
/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_execute.c,
__zend_lineno=2516) at
/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_API.c:594
#6 0x001b3b9c in _object_init_ex (arg=0x3a7560, class_type=0x320ce8,
__zend_filename=0x21bc10
/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_execute.c,
__zend_lineno=2516) at
/usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_API.c:610
#7 0x001cf42c in execute (op_array=0x31b4a0)
at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend_execute.c:2516
#8 0x001b1b18 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/php-4.3.0-dev-zend2-alpha1/Zend/zend.c:833
#9 0x001641fc in php_execute_script (primary_file=0xe8b8)
at /usr/local/php-4.3.0-dev-zend2-alpha1/main/main.c:1373
#10 0x001d6008 in main (argc=2, argv=0xe9a4)
at /usr/local/php-4.3.0-dev-zend2-alpha1/sapi/cli/php_cli.c:674
regards
--
Hakan Kuecuekyilmaz, University of Applied Sciences Esslingen, Germany
[EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register_globals vs session.force_nocookie
Giancarlo Pinerolo wrote: Jani Taskinen wrote: I was wondering (I'm propably wrong, it's almost 6am here :) that wouldn't the real fix for this without having to add yet-another-ini-option have been to fix this so that logic with session.use_cookies and session_use_trans_sid worked like it was (?) meant to work. I agree. That should be the same. But what about use_cookie=1 and use_trans_sid=1 situation? When should we allow to fallback from cookie to URL propagation? Shouldn't the GPC rule apply here too? I know the problem with the very first hit, when we know nothing of cookies enabled or not.. But the session offered in the url is checked and eventually created, before the firts redirect/cookie_check. SO at this point, before the initial redirect, we know if this is a 'living' or a 'newborn' session. I wonder if, even at the application level, it would make sense to trigger this with the canges in the propagation mode, and block any downgrade in propagation mode. But I slept only a few hours too. I mean by writing, once we know the session has just been created, a mode=new variable into the session... Then, returning from the very first redirect (mode==new): if a cookie is available, change mode=cookie if a cookie is not available, change mode='get'. On subsequent reenters, comparing the availability of the cookie with the mode setting, simply do not accept any change that has 'cookie' in only one of the two. Does it make sense as an interpretation of 'use cookies if they are available'? Giancarlo It is unusual that the same client would switch cookies on/off amid the way, and if this happens we are probably facing a client qui pro quo. Once the client has proven to be cookie-enabled, why should we accept a lower level, if we don't expressly want it (use cookies if they are enabled). I know counting on the possibility to force a downgrade in the propagation mode is a very common practice of writing code, but we should be able to do the same with a little bit more of control. So these directive should be overridable on a per script basis. Giancarlo ie. session.use_cookies=1 and session_use_trans_sid=0 would not use any other session id but the one provided by the cookie? btw. Cookies can be forged too.. --Jani On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote: Hi. Last here, same period, I found that nasty thing in ?_PHPLIB[libdir]=http:// It was the nefarious start of the register_globals=off saga. Now Sascha has agreed to add a session.use_only_cookie directive, because session.use_cookie wasn't doing it really all the times. In fact, contrary to what advertised, session.use_cookie doesn't uses cookies if a SID is found in the URL, and can so be forced to use a user_provided variable when it should not. The winning argument, for the new session.use_only_cookies, has been that, with the actual settings, there cannot exist a situation in which PHP would discard the ID in the URL, and go cookie_or_nothing, as the banks do. It is forceable. Even if the client has cookies enabled. You know, really secure sites use *only cookies* propagation, or you don't do your home banking. Because cookies are the closest thing that can assure that we are speaking to the same client, that noone can takeover a session. The basis for this behavior of session.use_cookie is that we may not know when coookies are enabled, not on the very first hit, when I suppose a redirect to self is made and the cookie is then checked for presence. The aim to use cookies, if available, is because cookie is an acronym of 'not transferrable among clients that support cookies', that is it goes as close as possible to identify a single client. My interpretation of session.use_cookie is: if cookies are enabled, try to use them as a propagation because they cannot be transferred among clients (see the acronym above). If this is the aim, and on coming back from the redirect we found a cookie, still the presence of a user-provided SID in the url should make us suspicious. If we want to prevent session takeovers, here we are in presence of a transfer. We couldn't know that cookies were enabled the very first hit, but now we know it, and there is a SID in the URL... someone is forcing a transfer. Discard the sid and issue a new cookie. Once we know cookies are enabled we should stick to them, not because they are a better way of storage, but because tey guarantee uniqness of the client. So why should we allow a transfer from outside? All this is apart from other concerns, as the possibility to create session_id at will, with pleasing and easy-to-remember values, to be offered around for those 'social engineering' attacks, with no hope for the poor cookie-enabled victim to avoid it. Isn't his similar to the
[PHP-DEV] Re: register_globals vs session.force_nocookie
Let's analyze the meaning of session.use_cookies, shall we? http://php.net/manual/en/ref.session.php says: session.use_cookies specifies whether the module will use cookies to store the session id on the client side. Defaults to 1 (enabled). Please note the absence of words like only. The combination of session.use_cookies=1 and session.use_trans_sid=0 is working perfectly fine at the moment. This is also not about forgery. While cookies are user data, the thing Mr. Pinerolo worries about is tricking a victim into using session ids which are known to the attacker. While it is easy for an attacker to send a URL to the victim containing a session id, injecting a malice cookie into the victim's system is a much harder job. I would say it is impossible, if I would not know about user habits and the quality of the software coming out of Redmond. Despite the availability of patches, many systems are simply not updated in a timely fashion. You also cannot compare this issue to register_globals, unless you are used to compare apples and oranges. With register_globals=on, a malice user can directly cause harm and severe damage to a service, if the scripts are badly written. For example, an attacker could inject SQL directly and cause all tables to be dropped. With session.use_only_cookies=0, an attacker has a tool for planting social engineering attacks against unwitting users. It does not cause direct damage on the server side. It is one way of thousands to manipulate users. Just look at how many AOL accounts are pfished each day, because users ignore the warning that noone will legitimately ask them for their password. Mr. Pinerolo's example of online banking is immune to this scheme, because all bank transactions are protected by a one-time pad (called TANs in Germany). I would not have come up with the session.use_only_cookies idea, if I did not see an advantage for using it under some circumstances. These circumstances are rare though and do not apply to all sites in general. Badly written PHP scripts are more common apparently which was the deciding factor for disabling register_globals. I do not foresee such a compatibility breaking step with regard to session.use_only_cookies. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] getting a suitable server for an upload script
hi i am creating a file upload script which will upload , insert into the db
and then ftp the file to a suitable server , depending on the file size
limit and how much space is left on the server , how could i check if the
filesize is between a range of values for the servers and choose the right
one
$filesize = round($file-getProp('size')/1000); //uploaded filesize
while ($servers = $result2-fetchRow(DB_FETCHMODE_ASSOC,$i++)) {
$file_limit = $servers[file_limit];
$ftpserver = $servers[server];
if ($filesize $file_limit) { echo $ftpserverbr$file_limitbr;}
//else if (($filesize $file_limit) and ($filesize 1000)) {echo
$ftpserverbr$file_limit;}
//else if ($filesize $file_limit) { echo
$ftpserverbr$file_limitbr;}
}
i am using this within an upload loop to upload each file , i dont think its
right though
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (1520 total including feature requests) ===[*Configuration Issues] 13561 Suspended --without-pear prevent install of php-config,phpize,... 15264 Feedback unable to include self when loaded as module 16184 Feedback Crashes during ./configure script 16311 Feedback php.ini-dist and php.ini-recommended missing extensions 16758 Assigned Configure Libraries have been installed in and where they really are 16920 Analyzed File permissions security problem 17320 Feedback invalid php_config.h for solaris 2.7 platform ===[*Directory/Filesystem functions] 12004 Assigned problem with fopen over ftp and a related fgets 12783 Open xmlDocFile needs absolute path 14076 Open fopen() and touch() fail to create file under safe mode 14100 Open Unicode Filenames 14657 Critical Sometimes mkdir(test1, 0777); $d=dir(test1); $d-close(); rmdir(test1); 16630 Open getlastmod() returns file access time, not modification time 17229 Feedback Permissions set incorrectly on newly created directories. 17471 Open Problem with Novell Netware map drive ===[*Extensibility Functions]= 15125 Feedback pnctl_signal does not handle class's as callbacks - patch included ===[*General Issues]== 15926 Feedback sum error 16094 Feedback Unable to view .php file in the browser 17287 Open safe mode is not full safe. 17353 Open Finish glob() support for all OS (hint: flags and portability) 17543 Feedback non-printable characters are converted to spaces when printing 17648 Open syslog inserts random characters into log files 17677 Open openlog warning and text edrror ===[*Graphics related] 15662 Open iptcembed FotoWare ===[*Languages/Translation]=== 11975 Analyzed mix of hebrew english ===[*Network Functions]=== 15639 Open detecting end of UDP packets 15988 Open Pending established tcp connections 16735 Open checkdnsrr claims not to be implemented ===[*PDF functions]=== 16911 Feedback Activate extention and PHP hangs ===[*Programming Data Structures]= 16304 Feedback Missing Error Messages ===[*Regular Expressions]= 17570 Open Memory leak ===[Apache related]=== 8866 Feedback Frozen applications with apache module running 9280 Open HTTP/1.1 Expect: header not honoured 9422 Open Apache hangs when Win goes to standby 10060 Open startup error msg format 11716 Open Segmentation fault(coredump) in Apache(DSO-enabled) startup 12992 Open php ignores Accept: text/vnd.wap.wml 13420 Open open_basedir breaks Apache SSI xbithack 13421 Open Problematic MIME-Type application/x-httpd-php 13925 Analyzed SCRIPT_NAME in Apache 1.3.22 wrong (or at least different) 13956 Open improve robustness against bad signal(2) et al. calls from third party libs 13961 Assigned some characters in incomonig variable names are silently changed 13964 Open core dump on AIX 4.3.2 14222 Open PHP Crashes with weird output often 14229 Open function virtual 14245 Open make install fails on apxs 14265 Open Make does not create php4lib.so. Apxs fails to copy it to apache dir 14401 Open Wrong include_path from Apache Directory config 14409 Open request for nonexistent file does not return 404 error 14662 Open Apache segvs on SIGHUP 14865 Feedback php4apache.dll - phpinfo error - winXP - Apache 15038 Open replace parameter of Header() function doesn't work in Apache module 15529 Open ap_cleanup_for_exec not used when creating 15954 Open problem on shutdown/oleaut32.dll 15968 Open make error when making apache 15970 Open fpassthru problem on Apache 1.3.23 (module) 16052 Open Some predefined variables allow GET overwrite 16233 Feedback Apache crashes on header() 16416 Feedback Unable to load Dynamic Libraries when mod_ssl enabled 16453 Open include_path in httpd.conf dosn't take effect when php installed Static 16515 Open Files with execute-bit are always php-parsed - I cannot disable this! 16725 Feedback test.php.dat also can be parsed 16801 Assigned httpd segementation fault at statup 16831 Open Apache/PHP proxy error? 17273 Feedback symbol not found 17283 Open register_tick_function(); 17424 Open Apache sends HTTP 500, but still sends PHP HTML without error 17469 Feedback After
[PHP-DEV] Re: [PHP-QA] Testers needed for bundled gd library in CVS
Current cvs buildscript seems broken: config.status: creating main/php_config.h ./config.status: 1541: Syntax error: done unexpected (expecting )) else cat $tmp/config.h rm -f $tmp/config.h fi done # LINE 1541 # # CONFIG_COMMANDS section. Platform: Intel OS: FreeBSD 4.5-RELEASE $ ./buildconf buildconf: checking installation... buildconf: autoconf version 2.52 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4.2 (ok) rebuilding configure rebuilding acconfig.h rebuilding main/php_config.h.in $ ./configure --prefix=/home/mdev/local \ --with-zlib-dir=/usr \ --enable-cli \ --with-gd=php \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Testers needed for bundled gd library in CVS
On Sat, Jun 15, 2002 at 03:46:14PM +0200, Melvyn Sopacua wrote : Current cvs buildscript seems broken: Please try the snapshot, they come with their own ./configure and test if it still fails. - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Testers needed for bundled gd library in CVS
At 15:59 15-6-2002, Markus Fischer shared with all of us: On Sat, Jun 15, 2002 at 03:46:14PM +0200, Melvyn Sopacua wrote : Current cvs buildscript seems broken: Please try the snapshot, they come with their own ./configure and test if it still fails. php4-200206150600 Still fails. Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Testers needed for bundled gd library in CVS
On Sat, Jun 15, 2002 at 04:56:30PM +0200, Melvyn Sopacua wrote : At 15:59 15-6-2002, Markus Fischer shared with all of us: On Sat, Jun 15, 2002 at 03:46:14PM +0200, Melvyn Sopacua wrote : Current cvs buildscript seems broken: Please try the snapshot, they come with their own ./configure and test if it still fails. php4-200206150600 Still fails. Time for a detailed bug report then. - Markus -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] Testers needed for bundled gd library in CVS
At 17:17 15-6-2002, Markus Fischer shared with all of us: On Sat, Jun 15, 2002 at 04:56:30PM +0200, Melvyn Sopacua wrote : At 15:59 15-6-2002, Markus Fischer shared with all of us: On Sat, Jun 15, 2002 at 03:46:14PM +0200, Melvyn Sopacua wrote : Current cvs buildscript seems broken: Please try the snapshot, they come with their own ./configure and test if it still fails. php4-200206150600 Still fails. Sorry - bogus. Had a hardcoded path to the cvs version in there. Snapshot supplied configure works. Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Zend Constants PATCH
Hello,
While developing software in PHP that supports i18n I've come across several
problems that affect defines made in PHP.
The first problem is that when a define is declared and its name contains
upper case characters such as I, the define becomes unusable if a locale,
which does not support those chracters is exported, such as tr_TR or ru_IU.
Bug Report at: http://bugs.php.net/bug.php?id=16865
There is a problem with case sensetivity of defines, for example, if you
create a case sensetive define 'TEST' and then a case sensetive define
'test', the latter define's value will be lost.
Bug Report at: http://bugs.php.net/?id=17658
The problem occurs because zend internally (zend_constants.c) seems to always
lowecase the define before it is fetched/added to the hash table of defines.
This causes problem for i18n because the define is lowercased using c's
tolower function, which is affected by locale settings. Because it is stored
as lower case, having 2 defines with the same name but in different case also
becomes impossible to do.
Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both
of these bugs, I hope the developers would consider adding this patch to the
CVS.
Ilia
--- zend_constants.c_old Sat Jun 15 13:02:40 2002
+++ zend_constants.c Sat Jun 15 12:59:11 2002
-226,8 +226,6
lookup_name = do_alloca(name_len+1);
memcpy(lookup_name, name, name_len+1);
- zend_str_tolower(lookup_name, name_len);
-
if (zend_hash_find(EG(zend_constants), lookup_name, name_len+1, (void **) c)==SUCCESS) {
if ((c-flags CONST_CS) memcmp(c-name, name, name_len)!=0) {
retval=0;
-255,7 +253,6
printf(Registering constant for module %d\n, c-module_number);
#endif
- zend_str_tolower(lowercase_name, c-name_len);
if (zend_hash_add(EG(zend_constants), lowercase_name, c-name_len, (void *) c, sizeof(zend_constant), NULL)==FAILURE) {
free(c-name);
if (!(c-flags CONST_PERSISTENT)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Does (will?) php support BerkeleyDB4 yet?
hi, is BerkelyDB4 supported in 5.8.0RC1? i note that -with-db has been deprecated, and that only -with-db2, -with-db3 and -with-dbm remain .. thanks for any comments/pointers. richard -- R Blake blakers at mac.com http://homepage.mac.com/blakers -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
What about a configuration option in php.ini use_case_sensitive = 0|1 and let it be 0 as default ? On Sat, 15 Jun 2002 22:25:18 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
We're not going to add configuration options which change the language's behavior! We've said this a million times. Andi At 09:41 PM 6/15/2002 +0200, Magnus M wrote: What about a configuration option in php.ini use_case_sensitive = 0|1 and let it be 0 as default ? On Sat, 15 Jun 2002 22:25:18 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
ok, sorry.. Missed that one.. On Sat, 15 Jun 2002 22:44:24 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: We're not going to add configuration options which change the language's behavior! We've said this a million times. Andi At 09:41 PM 6/15/2002 +0200, Magnus M wrote: What about a configuration option in php.ini use_case_sensitive = 0|1 and let it be 0 as default ? On Sat, 15 Jun 2002 22:25:18 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: Ilia, I remember now the problem you're talking about. It has been discussed here in the past and I don't recall us having found a good solution. Basically we need a solution which is backwards compatible but will allow TEST and test to co-exist if case sensitivity was chosen for them. It's something to think about and not create a quick 2 line patch for the problem. I think one of the suggestions was using two hash tables. First doing a case-sensitive lookup and only if the constant isn't found doing a case-insensitive lookup. Andi At 03:40 PM 6/15/2002 -0400, Ilia A. wrote: Andi, Yes, you are correct in that respect, my patch would accomplish just that. No where in PHP documentation does it say that you cannot have TEST and test defines in the same script. Unless you specifically tell the define() function to treat the define as case insensitive. Because the defines are always lowercased unless the defines for i18n systems are always declared in lower case any define with a letter 'I' for example would break on a system using most non English locales. This is a VERY serious problems, for example consider the reversal of the htmlenteties() function. The following code: get_html_translation_table (HTML_ENTITIES); will break if a ru_UI or tr_TR or any other number of non-English locales are exported. In addition because all locales are lower cased defines suffer large performance degradation when compared to other variables because another copy of the define name needs to be allocated and then lower cased every single time a define is declared or retrieved. As far as I know, php variables are always case sensitive and there is now way to make them not, why an exception was made for defines I do not know, especially when you consider that in C and C++ defines are ALWAYS case sensitive. IMHO this is a very bad feature, that not only implements useless functionality but actually causes PHP code to break. Therefor, I humbly ask that you reconsider your position on this issue. Ilia On June 15, 2002 03:03 pm, you wrote: Ilia, Your patch basically makes PHP constants case sensitive. Changing this is a very big backwards compatibility problem. You're not supposed to register two define's with the same letters but different case. Andi At 01:21 PM 6/15/2002 -0400, Ilia A. wrote: Hello, While developing software in PHP that supports i18n I've come across several problems that affect defines made in PHP. The first problem is that when a define is declared and its name contains upper case characters such as I, the define becomes unusable if a locale, which does not support those chracters is exported, such as tr_TR or ru_IU. Bug Report at: http://bugs.php.net/bug.php?id=16865 There is a problem with case sensetivity of defines, for example, if you create a case sensetive define 'TEST' and then a case sensetive define 'test', the latter define's value will be lost. Bug Report at: http://bugs.php.net/?id=17658 The problem occurs because zend internally (zend_constants.c) seems to always lowecase the define before it is fetched/added to the hash table of defines. This causes problem for i18n because the define is lowercased using c's tolower function, which is affected by locale settings. Because it is stored as lower case, having 2 defines with the same name but in different case also becomes impossible to do. Attached is a patch against zend_constants.c CVS revision 1.38 that fixes both of these bugs, I hope the developers would consider adding this patch to the CVS. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend Constants PATCH
Andi,
I wrote another patch, this time a 'proper' way, which means the old
functionality of case insensetivity is supported. Please look it over,
hopefuly this is good enough to commit.
I've also attached a small php test script you can use to see the problem in
non patched PHPs.
Ilia
On June 15, 2002 03:25 pm, Andi Gutmans wrote:
Ilia,
I remember now the problem you're talking about. It has been discussed here
in the past and I don't recall us having found a good solution. Basically
we need a solution which is backwards compatible but will allow TEST and
test to co-exist if case sensitivity was chosen for them.
It's something to think about and not create a quick 2 line patch for the
problem. I think one of the suggestions was using two hash tables. First
doing a case-sensitive lookup and only if the constant isn't found doing a
case-insensitive lookup.
Andi
At 03:40 PM 6/15/2002 -0400, Ilia A. wrote:
Andi,
Yes, you are correct in that respect, my patch would accomplish just that.
No where in PHP documentation does it say that you cannot have TEST and
test defines in the same script. Unless you specifically tell the
define() function to treat the define as case insensitive.
Because the defines are always lowercased unless the defines for i18n
systems are always declared in lower case any define with a letter 'I'
for example would break on a system using most non English locales. This
is a VERY serious problems, for example consider the reversal of the
htmlenteties() function. The following code:
get_html_translation_table (HTML_ENTITIES);
will break if a ru_UI or tr_TR or any other number of non-English locales
are exported.
In addition because all locales are lower cased defines suffer large
performance degradation when compared to other variables because another
copy of the define name needs to be allocated and then lower cased every
single time a define is declared or retrieved.
As far as I know, php variables are always case sensitive and there is now
way
to make them not, why an exception was made for defines I do not know,
especially when you consider that in C and C++ defines are ALWAYS case
sensitive. IMHO this is a very bad feature, that not only implements
useless functionality but actually causes PHP code to break.
Therefor, I humbly ask that you reconsider your position on this issue.
Ilia
On June 15, 2002 03:03 pm, you wrote:
Ilia,
Your patch basically makes PHP constants case sensitive.
Changing this is a very big backwards compatibility problem.
You're not supposed to register two define's with the same letters but
different case.
Andi
At 01:21 PM 6/15/2002 -0400, Ilia A. wrote:
Hello,
While developing software in PHP that supports i18n I've come across
several problems that affect defines made in PHP.
The first problem is that when a define is declared and its name
contains upper case characters such as I, the define becomes unusable
if a locale, which does not support those chracters is exported, such
as tr_TR or ru_IU. Bug Report at:
http://bugs.php.net/bug.php?id=16865
There is a problem with case sensetivity of defines, for example, if
you create a case sensetive define 'TEST' and then a case sensetive
define 'test', the latter define's value will be lost.
Bug Report at: http://bugs.php.net/?id=17658
The problem occurs because zend internally (zend_constants.c) seems to
always lowecase the define before it is fetched/added to the hash
table of defines. This causes problem for i18n because the define is
lowercased using c's tolower function, which is affected by locale
settings. Because it is stored as lower case, having 2 defines with
the same name but in different case also becomes impossible to do.
Attached is a patch against zend_constants.c CVS revision 1.38 that
fixes both
of these bugs, I hope the developers would consider adding this patch
to the CVS.
Ilia
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
?php
define('TEST', TEST #1);
define('test', test #2);
echo TEST.\n;
echo test.\n;
/* User case define */
define('NO_CASE', 'case insensetive constant', TRUE);
echo NO_CASE.\n;
echo no_case.\n;
echo No_CaSe.\n;
/* PHP Made case Defines */
echo TRUE.\n;
echo trUe.\n;
echo TrUe.\n;
/* I18n test */
define('iii', 'i18n');
setlocale('LC_ALL', 'tr_TR');
echo iii.\n;
?
--- zend_constants.c_old Sat Jun 15 17:46:53 2002
+++ zend_constants.c Sat Jun 15 18:09:59 2002
-222,12 +222,12
zend_constant *c;
char *lookup_name;
int retval;
-
- lookup_name = do_alloca(name_len+1);
- memcpy(lookup_name, name, name_len+1);
-
- zend_str_tolower(lookup_name, name_len);
-
+ int c_flag;
+
+ c_flag=1;
+ lookup_name = name;
+
+ casechk:
if (zend_hash_find(EG(zend_constants), lookup_name,
[PHP-DEV] Calling other PHP functions from your extension
Hello, I've been messing around with my own PHP extension for a couple of days now (I was pleasantly surprised to find how easy it was to write one!), one I've been meaning to write for over a year and I had a couple of questions I hope I can get some help on: i) is it possible to call other functions in PHP from your functions? In particular, I'd like to eval() a string I have and return the resultant string to the user -- is there anyway I can do this? ii) I'm making fast progress in my extension, and I think it might be something that might be worthy of inclusion into the main PHP distribution. What steps are involved in submitting a module for such consideration? Wood Shavings! Andrew Patterson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling other PHP functions from your extension
Take a look at http://www.php.net/manual/en/zend.calling-user-functions.php I guess that's what you need. What is your extension about? Fab. - Original Message - From: Andrew Patterson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 15, 2002 8:33 PM Subject: [PHP-DEV] Calling other PHP functions from your extension Hello, I've been messing around with my own PHP extension for a couple of days now (I was pleasantly surprised to find how easy it was to write one!), one I've been meaning to write for over a year and I had a couple of questions I hope I can get some help on: i) is it possible to call other functions in PHP from your functions? In particular, I'd like to eval() a string I have and return the resultant string to the user -- is there anyway I can do this? ii) I'm making fast progress in my extension, and I think it might be something that might be worthy of inclusion into the main PHP distribution. What steps are involved in submitting a module for such consideration? Wood Shavings! Andrew Patterson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Does (will?) php support BerkeleyDB4 yet?
hi, is BerkelyDB4 supported in 5.8.0RC1? i note that -with-db has been deprecated, and that only -with-db2, -with-db3 and -with-dbm remain .. thanks for any comments/pointers. Hey, could i get a copy of 5.8.0RC1 please? -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CORRECTION: [PHP-DEV] Does (will?) php support BerkeleyDB4 yet?
make that in 4.2.1 or 4.3.x. working on php perl - got my versions crossed . hi, is BerkelyDB4 supported in 5.8.0RC1? i note that -with-db has been deprecated, and that only -with-db2, -with-db3 and -with-dbm remain .. thanks for any comments/pointers. Hey, could i get a copy of 5.8.0RC1 please? -- james -- R Blake blakers at mac.com http://homepage.mac.com/blakers -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling other PHP functions from your extension
Take a look at http://www.php.net/manual/en/zend.calling-user-functions.php
I guess that's what you need.
Hmmm. I'm not sure, but I thought this was about calling user-defined
functions, not existing PHP module functions. Looking at my last email,
I probably wasn't clear enough :P I don't want to call a passed in
function name a la a callback; I want to call a core PHP function like
implode(), or explode() or mysql_connect() (for example) --
specifically, I need to call the eval() function. Can you do that in the
manner defined for calling user functions? Are the functions explode,
implode, etc. in the user function table? I thought those just contained
the functions that had been defined by the user in the currently being
parsed script -- not all functions defined by loaded modules. Am I wrong?
What is your extension about?
I'm the author/maintainer of a pair of PHP libraries named the NDBE
the NObjects (http://ndbe.sourceforge.net); the former is a database
editor/ abstact layer library, and the latter is general 'odds and ends'
library of scripts, some of which the former requires to run.
One such script emulates the Windows registry, providing a persistant,
filesystem-like hive/key/value system for storing information in various
formats. The scripts provides an object (NHive) that allows you to
access this 'registry', which is actually stored on the drive in a
file-tree (at a location you specify). Furthermore, we expand on the
idea of the registry to add in the concept of 'ethereal hives'. If
you're familliar with the Windows registry, picture them as sort of a
read-only hive (like HKEY_LOCAL_USER) which is only used if the
requested key/value can't be found in the *actual* hive (of the same
name). Ethereal hives sort of provide a set of default values; the first
time you ask for 'HIVE/foobar/foo', and it can't find it in the *real*
registry, it looks it up in the ethereal hive of the same name ('HIVE'
in this case). If it finds a key 'foobar' with a value 'foo', it would
return that value contained in 'foo'. If you write out a new value to
'HIVE/foobar/foo' it will write it to the REAL registry however; and
ever after when it ask for that key ('HIVE/foobar/foo') it will give you
the value from the real registry, which you just created and set. It's a
little confusing to explain, but solves a wide variety of problems we
had with default values, and allows you to do wonderful things with
checking them in. In short, it can -- for the most part -- allow you to
do away with configuration files.
It works very well, and we (my partners I) have found it *very* useful
over the last couple of years, and most of the NObjects and all of the
NDBE runs on it. We had the natural idea of making it into a PHP module
more than a year ago, but none of us could find the time -- I finally
did a few days ago and was surpised how quickly it's come along.
Of course, all of the logic is more or less written out for me; it's in
the NHive.php script :) It's just a matter or converting the code to a
somewhat lower-level language (namely C) and making it properly-cross
platform. I intend to make the Win32 version use the *actual* Windows
registry, but that's for later -- haven't ever actually *used* PHP on
Windows before.
Anyways, that's the (long-winded) explanation. I've got 95% of the
utility functions written, I just have to do the set/get/create/delete
functions. After that, I'll be thoroughly testing it (fortunately I have
a complete library and application in the NDBE to test it on) and then
be submitting it wherever it should be submitted for consideration --
assuming someone's interested. Otherwise, I guess it'll just be posted
on sourceforge or freshmeat :)
Wood Shavings!
Andrew Patterson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: register_globals vs session.force_nocookie
[EMAIL PROTECTED] (Sascha Schumann) wrote: --- Let's analyze the meaning of session.use_cookies, shall we? http://php.net/manual/en/ref.session.php says: session.use_cookies specifies whether the module will use cookies to store the session id on the client side. Defaults to 1 (enabled). Please note the absence of words like only. The combination of session.use_cookies=1 and session.use_trans_sid=0 is working perfectly fine at the moment. This is also not about forgery. While cookies are user data, the thing Mr. Pinerolo worries about is tricking a victim into using session ids which are known to the attacker. While it is easy for an attacker to send a URL to the victim containing a session id, injecting a malice cookie into the victim's system is a much harder job. I would say it is impossible, if I would not know about user habits and the quality of the software coming out of Redmond. Despite the availability of patches, many systems are simply not updated in a timely fashion. You also cannot compare this issue to register_globals, unless you are used to compare apples and oranges. With register_globals=on, a malice user can directly cause harm and severe damage to a service, if the scripts are badly written. For example, an attacker could inject SQL directly and cause all tables to be dropped. With session.use_only_cookies=0, an attacker has a tool for planting social engineering attacks against unwitting users. It does not cause direct damage on the server side. It is one way of thousands to manipulate users. Just look at how many AOL accounts are pfished each day, because users ignore the warning that noone will legitimately ask them for their password. Mr. Pinerolo's example of online banking is immune to this scheme, because all bank transactions are protected by a one-time pad (called TANs in Germany). I would not have come up with the session.use_only_cookies idea, if I did not see an advantage for using it under some circumstances. These circumstances are rare though and do Frankly, what I think of this is that it is a piece of social engineering in itself. The new session.use_only_cookies directive, put like that, that can only be set on a per installation basis, will never be adopted. This will leave all sites in the world vulnerable to damn easy snooping. I understand there are historical reasons for trying to keep the status quo, probably too many applications rely on the actual weakness. I do not share that vision. Anyway this will come back to your face one day, I have no doubts about it. This is not my problem, I'll be fairly offshore for the next months, so really you do what you want, discuss it or impose it among yourselves, I've done my duty. Mr. Pinerolo not apply to all sites in general. Badly written PHP scripts are more common apparently which was the deciding factor for disabling register_globals. I do not foresee such a compatibility breaking step with regard to session.use_only_cookies. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Calling other PHP functions from your extension
Well have you tried it?
Use the same example, and instead of putting test_function, put phpinfo,
or any php function that doesn't take parameters, and see the result, it
works!
To pass parameters to the function you want to call, it's a bit more
complicated. Take a look at the call_user_function declaration in
zend_API.h, you will see that there is one field called parameter_count
(that's easy to understand what this is for), and the next field is
params. Those are zvals, so it's easy, put the parameters in this array as
zvals, set the correct parameter count and bingo.
Note that the documentation is WRONG. The call to call_user_function_ex is
incorrect, it doesn't have the right number of parameters. For your case,
you'd better go with call_user_function for now, not the ex one. Also, it
should read TSRMLS_FETCH, not TSRMSLS_FETCH (don't forget this macro or you
will loose the thread safe context).
Fab.
- Original Message -
From: Andrew Patterson [EMAIL PROTECTED]
To: fabwash [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, June 16, 2002 1:38 AM
Subject: Re: [PHP-DEV] Calling other PHP functions from your extension
Take a look at
http://www.php.net/manual/en/zend.calling-user-functions.php
I guess that's what you need.
Hmmm. I'm not sure, but I thought this was about calling user-defined
functions, not existing PHP module functions. Looking at my last email,
I probably wasn't clear enough :P I don't want to call a passed in
function name a la a callback; I want to call a core PHP function like
implode(), or explode() or mysql_connect() (for example) --
specifically, I need to call the eval() function. Can you do that in the
manner defined for calling user functions? Are the functions explode,
implode, etc. in the user function table? I thought those just contained
the functions that had been defined by the user in the currently being
parsed script -- not all functions defined by loaded modules. Am I wrong?
What is your extension about?
I'm the author/maintainer of a pair of PHP libraries named the NDBE
the NObjects (http://ndbe.sourceforge.net); the former is a database
editor/ abstact layer library, and the latter is general 'odds and ends'
library of scripts, some of which the former requires to run.
One such script emulates the Windows registry, providing a persistant,
filesystem-like hive/key/value system for storing information in various
formats. The scripts provides an object (NHive) that allows you to
access this 'registry', which is actually stored on the drive in a
file-tree (at a location you specify). Furthermore, we expand on the
idea of the registry to add in the concept of 'ethereal hives'. If
you're familliar with the Windows registry, picture them as sort of a
read-only hive (like HKEY_LOCAL_USER) which is only used if the
requested key/value can't be found in the *actual* hive (of the same
name). Ethereal hives sort of provide a set of default values; the first
time you ask for 'HIVE/foobar/foo', and it can't find it in the *real*
registry, it looks it up in the ethereal hive of the same name ('HIVE'
in this case). If it finds a key 'foobar' with a value 'foo', it would
return that value contained in 'foo'. If you write out a new value to
'HIVE/foobar/foo' it will write it to the REAL registry however; and
ever after when it ask for that key ('HIVE/foobar/foo') it will give you
the value from the real registry, which you just created and set. It's a
little confusing to explain, but solves a wide variety of problems we
had with default values, and allows you to do wonderful things with
checking them in. In short, it can -- for the most part -- allow you to
do away with configuration files.
It works very well, and we (my partners I) have found it *very* useful
over the last couple of years, and most of the NObjects and all of the
NDBE runs on it. We had the natural idea of making it into a PHP module
more than a year ago, but none of us could find the time -- I finally
did a few days ago and was surpised how quickly it's come along.
Of course, all of the logic is more or less written out for me; it's in
the NHive.php script :) It's just a matter or converting the code to a
somewhat lower-level language (namely C) and making it properly-cross
platform. I intend to make the Win32 version use the *actual* Windows
registry, but that's for later -- haven't ever actually *used* PHP on
Windows before.
Anyways, that's the (long-winded) explanation. I've got 95% of the
utility functions written, I just have to do the set/get/create/delete
functions. After that, I'll be thoroughly testing it (fortunately I have
a complete library and application in the NDBE to test it on) and then
be submitting it wherever it should be submitted for consideration --
assuming someone's interested. Otherwise, I guess it'll just be posted
on sourceforge or freshmeat :)
Wood Shavings!
Andrew Patterson
--
PHP Development
