Re: [PHP-DEV] Errors while building latest snapshot

[Martin Jansen]

On Thu Aug 15, 2002 at 01:5043AM +0200, Marcus Börger wrote:
> Could you try cvs version again?

Build fine now. Thanks for your help.

-- 
- Martin   Martin Jansen
http://martinjansen.com/

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Errors while building latest snapshot

[Marcus Börger]

Could you try cvs version again?

marcus

At 13:49 14.08.2002, Martin Jansen wrote:
>While building the latest snapshot, I get the following error during
>"make":
>
>ext/standard/info.lo: In function `php_print_info':
>/home/martin/source/php4-200208140300/ext/standard/info.c:233:
>undefined reference to `iconv_globals'
>collect2: ld returned 1 exit status
>make: *** [sapi/cli/php] Error 1
>
>My configure options are:
>
>'./configure' \
>'--with-apxs=/usr/local/apache/current/bin/apxs' \
>'--with-mysql=/usr/local/mysql/current/' \
>'--with-pgsql=/usr/local/pgsql/current/' \
>'--with-interbase=/opt/interbase/' \
>'--with-zlib' \
>'--enable-ftp' \
>'--with-mcal=/usr/include/mcal/' \
>'--with-gettext=/usr/local/' \
>'--enable-track-vars' \
>'--enable-url-includes' \
>'--enable-trans-sid' \
>'--enable-sysvsem' \
>'--enable-sysvshm' \
>'--enable-sockets' \
>'--enable-bcmath' \
>'--with-config-file-path=/etc' \
>'--with-sablot=/usr' \
>'--with-xmlrpc' \
>'--enable-tokenizer' \
>"$@"
>
>Any clues?
>
>--
> - Martin   Martin Jansen
> http://martinjansen.com/
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Yasuo Ohgaki]

Melvyn Sopacua wrote:
> At 15:46 14-8-2002, Alan Knowles wrote:
> 
> 
>> Can we not document the real issues about this in the manual, and just 
>> say something like
>>
>> There are security issues in using any type of sessions with HTTP, 
>> please read the manual at
>> http://www.php.net/en/manual/security.sessions.html
>> for a more detail discussion on this subject..
> 
> 
> 
> How's the attached for starters.
> 
> It's not perfect, as I'm looking for the docbook equivalent of strong,
> but concentrate on the text please.

Patch applied.
It seems I forgot to update trans-sid ini description and
source default. It's fixed also.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Bug #10374 [Opn->Bgs]: Depreciated features or not

[Yasuo Ohgaki]

Ilia A. wrote:
> On August 14, 2002 02:05 am, you wrote:
> 
>>Hi Ilia,
>>
>>One of the compaliant about PHP is things has been
>>depreciated/changed w/o proper prior notice. Many
>>users are tried with the _bad_ practice AFAIK.
> 
> 
> Well depreciation does not mean the functions were removed, it simply means 
> that there is an advisory by developers indicating that the function MAY be 
> removed at some future point.
> Now, if you consider other languages, or libraries like glibc for example, 
> they do depreciate functions once in the blue moon. When that is done during 
> compilation, unless error level is set to nill you would get a notice from 
> the compiler indicating that a certain function has been depriciated and you 
> should use function XYZ as an alternative.
> 
> Perphaps, we should do the same for PHP?

A few issues are needed to be resolved, but it may work.

Anyway, We are better to have loadmap for both developer and
users.

Why? I guess we don't have agreement how PECL is used still,
and/or which module should be moved to PECL, for example.
There are many things that are better to be described/notified.

I posted the feature request so that someone is interested
someday, since not many people are interested last time I
asked here.

--
Yasuo Ohgaki


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Problem with include_once/require_once & remote URLs

[Ilia A.]

According to the PHP manual _once functions support inclusion of remote URLs, 
which they do. However, unlike when dealing with local files those functions 
do not actually keep track of how many times the file is included and prevent 
double inclusion of the same file. Meaning that those functions offer no 
extra functionality when dealing with remote URLs.
In addition Zend code which handles include_once/require_once logic also does 
not insert the remote URLs into the included_files hash table, so according 
to functions get_included_files() and get_required_files those files are not 
even included.

The attached patch modifies zend_execute.c, which allows the same kind of 
functionality that prevents double inclusion of the same file on local drive 
to work on remote URLs as well. Consequently it will also make remotely 
included files appear in the included_files hash table.

Here are 2 small test scripts that can be used to test existing & patched 
code.
hello
Array
(
[0] => /home/rei/a.php
[1] => http://localhost/a.php
)

b.php:
http://localhost/a.php";;
include_once "http://localhost/a.php";;

print_r(get_included_files());
?>

a.php:



PHP 4.3.0

hello
hello
Array
(
[0] => /home/rei/a.php
)

PHP 4.3.0 + patch
-
hello
Array
(
[0] => /home/rei/a.php
[1] => http://localhost/a.php
)


Ilia

P.S. This is not something new, in fact I came across this problem in an 
existing bug report at http://bugs.php.net/16150

--- zend_execute.c	Wed Aug 14 17:45:02 2002
+++ zend_execute.c_new	Wed Aug 14 17:42:18 2002
@@ -2084,6 +2084,7 @@
 		case ZEND_REQUIRE_ONCE: {
 char *opened_path=NULL;
 int dummy = 1;
+int remote_file = 0;
 zend_file_handle file_handle;
 
 file_handle.handle.fp = zend_fopen(inc_filename->value.str.val, &opened_path);
@@ -2093,9 +2094,15 @@
 file_handle.free_filename = 0;
 
 if (file_handle.handle.fp) {
-	if (!opened_path || zend_hash_add(&EG(included_files), opened_path, strlen(opened_path)+1, (void *)&dummy, sizeof(int), NULL)==SUCCESS) {
+	if( !opened_path ) {
+		opened_path = estrdup(inc_filename->value.str.val);
+		remote_file = 1;
+	}	
+
+	if (zend_hash_add(&EG(included_files), opened_path, strlen(opened_path)+1, (void *)&dummy, sizeof(int), NULL)==SUCCESS) {
 		new_op_array = zend_compile_file(&file_handle, (EX(opline)->op2.u.constant.value.lval==ZEND_INCLUDE_ONCE?ZEND_INCLUDE:ZEND_REQUIRE) TSRMLS_CC);
 		zend_destroy_file_handle(&file_handle TSRMLS_CC);
+		if( remote_file ) efree(opened_path);
 		opened_path = NULL; /* zend_destroy_file_handle() already frees it */
 	} else {
 		fclose(file_handle.handle.fp);



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] CVS Account Request: m_alnasri31

[Dan Hardiker]

> PHP is very Good.

and you require a PHP CVS account because ... heh

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

> On the other hand, if you know the user's credentials, why bother to
> fake anything -- just log in to the system like anyone else!

Thats user security - only user training can do that.

> So... In a system where eavesdropping or man-in-the-middle attacks are
> not possible (ie. HTTP over SSL), HTTP Basic Authentication is secure.

As secure as any other method suggested [eg: cookies] yes - but no more or
less secure.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: m_alnasri31

[Mohamad Saleh]

PHP is very Good.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Marko Karppinen]

Dan Hardiker:
> However, HTTP basic authentication is passed the same as session 
> cookies
> (discussed earlier in this thread) - in the headers of the HTTP
> communication. This can very easily be faked with something like cURL.

On the other hand, if you know the user's credentials, why bother to 
fake anything -- just log in to the system like anyone else!

So... In a system where eavesdropping or man-in-the-middle attacks are 
not possible (ie. HTTP over SSL), HTTP Basic Authentication is secure. 
So it makes sense the piggybag the session id propagation on it also.

mk


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] Apache2+safe_mode

[Scott Lamb]

The attached patch fixes  by 
implementing the necessary php_apache_sapi_get_stat function. As I wrote 
in the comment, it does one more system call than is strictly necessary 
and won't help in cases where the request does not originate from a 
file. It's a pretty clear improvement over the current situation, though.

-- 
Scott Lamb


Index: sapi/apache2filter/sapi_apache2.c
===
RCS file: /repository/php4/sapi/apache2filter/sapi_apache2.c,v
retrieving revision 1.81
diff -u -r1.81 sapi_apache2.c
--- sapi/apache2filter/sapi_apache2.c   28 Jun 2002 14:45:10 -  1.81
+++ sapi/apache2filter/sapi_apache2.c   19 Jul 2002 03:50:38 -
@@ -208,6 +208,18 @@
}
 }
 
+static struct stat *php_apache_sapi_get_stat(TSRMLS_D)
+{
+   request_rec *rec;
+   rec = ((php_struct*)SG(server_context))->r;
+   if (stat(rec->canonical_filename, &SG(global_stat)) != 0) {
+   ap_log_error(APLOG_MARK, APLOG_ERR | APLOG_STARTUP,
+0, NULL, "Can't stat \"%s\"", 
+rec->canonical_filename);
+   return NULL;
+   }
+   return &SG(global_stat);
+}
+
 static void php_apache_sapi_log_message(char *msg)
 {
php_struct *ctx;
@@ -242,7 +254,7 @@
 
php_apache_sapi_ub_write,   /* unbuffered write */
php_apache_sapi_flush,  /* flush */
-   NULL,   /* get 
uid */
+   php_apache_sapi_get_stat,   /* get uid */
NULL,   /* 
getenv */
 
php_error,  /* 
error handler */



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] current warnings on compaq tru64

[Sebastian Nohn]

http://nohn.net/lalafarm/200208140900-error.log

Regards,
   Sebastian Nohn
-- 
+49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/
PGP Key Available - Did I help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

>> So if Im to write an online web-based banking system (either in
>> Java/JSP,
>> PHP, ASP - whatever)... what method would you suggest that IS secure?
>
> As for the propagation of the session id, there is only one
> pseudo-secure
> method -- using HTTP basic authentication. On authenticated pages, the
> following code can be used to make the session id dependent on the
> authentication credentials passed on by the user. I'm quite happy with
> it on various sites.

However, HTTP basic authentication is passed the same as session cookies
(discussed earlier in this thread) - in the headers of the HTTP
communication. This can very easily be faked with something like cURL.

The only secure way I have found has been flash inside the web browser,
with a blowfish encryption handler. Then the flash app talks to the PHP
scripts over HTTPS communicating in XML and passing the session back and
forward there.

The only way around it is to log every single packet and use packet
reconstruction after putting it though a SSL handler and then parse the
TCP communication... but theres no way around that one.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Marko Karppinen]

> So if Im to write an online web-based banking system (either in 
> Java/JSP,
> PHP, ASP - whatever)... what method would you suggest that IS secure?

As for the propagation of the session id, there is only one 
pseudo-secure
method -- using HTTP basic authentication. On authenticated pages, the
following code can be used to make the session id dependent on the 
authentication credentials passed on by the user. I'm quite happy with 
it on various sites.

First, in php.ini, we turn off other methods of propagation:
 session.use_trans_sid = Off
 session.use_cookies = Off

Then, *after the user has been authenticated*, we do this:
 if (isset($PHP_AUTH_USER) && isset($PHP_AUTH_PW)) {
 session_id(md5("magiccookie".$PHP_AUTH_USER.$PHP_AUTH_PW));
 }
 session_start();

To my knowledge, this method is completely secure when transport layer 
security (ie. SSL) is used, and, when not, as secure as most other 
authentication methods where the credentials are transmitted in 
cleartext. In my book, this makes it considerably cleaner a propagation 
method than the other alternatives.

If someone is documenting the session propagation stuff, maybe this 
should be mentioned.

mk


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Problems uploading large files

[Michael Kunze]

Hi all,

there are some bug reports regarding large file uploads, but here is an 
observation that might give additional hints for solving the problem:

I'm not able to upload files via HTTP POST greater than 102574 KByte 
(with Mozilla 1.1). This applies no mater what i set max_upload_size, 
post_max_size, upload_max_filesize and memory_limit to.

When the above limit of data is reached, the tmpfile vanishes from the 
tmp folder and Apache writes the log line below:

[error] PHP Warning:  Only 1284 bytes were written, expected to write 
5119 in Unknown on line 0

This is slightly different with uploading using IE. Here the maximum 
upload size is  about 103408 KByte, after which the same behaviour can 
be observed.

The error message states:

[Wed Aug 14 18:04:37 2002] [error] PHP Warning:  Only 2255 bytes were 
written, expected to write 5119 in Unknown on line 0

With files below 100MByte size everything works fine.

Does anybody have a clue what's going on here? PHP version is 4.2.2 with 
Apache 1.3.26 on Linux.

Cheers

Michael


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] S

[Gustavo Almeida]

Caro php-dev,

  

-- 
Sds;
 Gustavo Almeida
 [EMAIL PROTECTED]
 Web Developer
 Medsys On Line
 www.medsys.com.br
 (27)3332-2027


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: my little php-ext/java-RMI extension

[norbert frese]

and here are the files!

http://www.scheinwelt.at/~norbertf/files/php-java-rmi-remotecontrol.zip

n.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Melvyn Sopacua]

At 17:22 14-8-2002, Rasmus Lerdorf wrote:

>Guys, documentation is about giving people information that will help them
>solve problems, not about FUD.  That was my original point about the
>php.ini entry.  You can't just state that something is very very bad
>without giving workable solutins and alternatives.
>
>Present ways of solving the problem and mention the security implications
>of each solution and thereby allow people to make informed decisions.
>
>The blurb below is better than the original php.ini warning, but it still
>does not really give the user a set of solutions.

Ok - good point.

So before I rewrite this, are we going to take that road, or just delete
the php.ini entry.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Melvyn Sopacua]

At 17:15 14-8-2002, Dan Hardiker wrote:

> > +
> > + Therefore, when dealing with sensative information, there should +
> > always be additional methods to decide whether it is a valid +
> > session. Sessions are not reliable as a secure +
> > authentication mechanism.
> > +
>
>So if Im to write an online web-based banking system (either in Java/JSP,
>PHP, ASP - whatever)... what method would you suggest that IS secure?

HTTPS and idealy kerberos and/or some calculator skey or irisscans. But
the main culprit is that no sessions act as a deciding factor alone, just an
alternate data storage method, that is quicker than a multi-joined query.
If the session is invalid, create a new one and do the query again or display
an error. No harm other than speed and usability, which in case of banking
are of lower priority than security.

Ultimately you can only identify a browser, never a person, so I would use
a plugin that closes all browser windows after x minutes of inactivity,
regardless of sessions, but at some point the responsibility stops and the
end-user is to blame.

The main problems I see though, are with shopping carts. These can reveal
whether someone is on prozac for instance. The cart is a session variable
and with 99% of the shops no authentiation has taken place, when creating
a cart. This is only done, when people are checking out and proceeding to
the order form. Most of them, don't even encode the order form, but only
the billing.

At 16:23 14-8-2002, Stefan Esser wrote:

>I do not understand the sense of this whole discussion.
>HTTP is a plaintext protocol. So nothing transfered over HTTP can be secure.
>No urls, no session no anything.

Yes. So we either advise nothing or correctly, which is what the discussion
boiled down to.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

>> I absolutely agree with Stefan here. It is *not* PHP's job to secure
>> a connection. SSL does this.
>
> Like that's going to stop users from pasting url with SID in it to an
> email, which is what this thread is about.

There are 2 issues at play here, firstly is educating PHP site builders
that using HTTPS would enable a secure method of communication to stop
packet sniffing and stream caching.

Secondly, is educating the PHP users to the cause and effect cycle (the
issues) with using things like session's, their client-side storage
methods etc.

HTTPS should be used where nessesary yes - but we currently have no
alternative to sessions ... not a good, http-universally usable one.

If we can come up with a universal alternative that can be used - then
lets go for it ... if not, were gonna just have to live with the best we
have.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] my little php-ext/java-RMI extension

[norbert frese]

hi!

i have written a little extension to the php-java module to allow 
convenient access to objects living in other virtual machines via rmi. 
this should be handy because the php-java JVM terminates at the end of 
every php-script.

the idea was to make remote objects look like local objects:

---
   $dow = new 
Java("rmi/RemoteControllable1.0","//192.168.2.20:5002/remoteControlDemo_dowJonesInfo");

   $dow->changeValue(1000);

   $value = $dow->getValue();

   print "getValue() of remote dowJonesInfo-Object: " . $value  . "\n";

because i use a generic wrapper for remote-objects 
(RemoteControllableImpl), they don't have to be available in the 
classpath of php-java.

i have hacked the reflect.java-class to handle both local objects and 
remote objects. methods on remote-objects are handled via reflection on 
the remote-side (which need to be plugged into my RemoteControllableImpl 
class).

!!! i have used the reflect.java from PHP 4.0.6 which might not be up to 
date.

to test my extension you have to replace the php_java.jar and start 
runRemoteControlTestSrv.bat.
i hope you like it!

cheers

norbert



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Edin Kadribasic]

> I absolutely agree with Stefan here. It is *not* PHP's job to
secure
> a connection. SSL does this.

Like that's going to stop users from pasting url with SID in it to
an email, which is what this thread is about.

Edin


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Daniel Lorch]

hi,

I absolutely agree with Stefan here. It is *not* PHP's job to secure
a connection. SSL does this. 

-daniel

- Original Message -
From: "Stefan Esser" <[EMAIL PROTECTED]>
Sent: Wed, 14 Aug 2002 16:23:16 +0200
To: <[EMAIL PROTECTED]>
Subject: Re: [PHP-DEV] trans-sid warning?

> I do not understand the sense of this whole discussion.
> HTTP is a plaintext protocol. So nothing transfered over HTTP can be secure.
> No urls, no session no anything.
> 
> Stefan
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Rasmus Lerdorf]

Guys, documentation is about giving people information that will help them
solve problems, not about FUD.  That was my original point about the
php.ini entry.  You can't just state that something is very very bad
without giving workable solutins and alternatives.

Present ways of solving the problem and mention the security implications
of each solution and thereby allow people to make informed decisions.

The blurb below is better than the original php.ini warning, but it still
does not really give the user a set of solutions.

-Rasmus

On Wed, 14 Aug 2002, Melvyn Sopacua wrote:

> Inlined for the list.
>
> Index: reference.xml
> ===
> RCS file: /repository/phpdoc/en/reference/session/reference.xml,v
> retrieving revision 1.8
> diff -u -r1.8 reference.xml
> --- reference.xml   28 Jul 2002 14:04:32 -  1.8
> +++ reference.xml   14 Aug 2002 13:58:04 -
> @@ -46,6 +46,41 @@
>   
>  
>
> +   
> +Sessions and security
> +
> + Using sessions, does not mean, you can be absolutely sure, that
> + the session data can only be viewed by that user. This is impor-
> + tant to keep in mind, when storing and displaying sensative
> + information. When storing data into a session, one should always
> + ask themselves, what the damage is, when somebody else views that
> + information, or how your application is affected when this session
> + is actually somebody else.
> +
> +
> + For instance, if somebody else takes a session, can he than post
> + a message in a forum, as that user and how big of a problem is that?
> + Or perhaps he can view what the original user was thinking of
> + ordering, because he gets access to that user's shopping cart.
> + Obviously for a flowershop, this is less dramatic, than for a
> + farmacy.
> +
> +
> + Therefore, when dealing with sensative information, there should
> + always be additional methods to decide whether it is a valid
> + session. Sessions are not reliable as a secure
> + authentication mechanism.
> +
> +
> + Sessions rely on the session ID, meaning one can 'steal' a session,
> + by stealing the session ID. This can be made harder, by using a cookie
> + specifically a session cookie, but does not in any way make it
> + impossible and still relies on the user closing all
> + browser windows, to expire the session cookie.
> + Besides that, even session cookies can be sniffed on a network or
> + logged by a proxyserver.
> +
> +   
>  
>   &reftitle.required;
>   &no.requirement;
>
>
>
> Met vriendelijke groeten / With kind regards,
>
> Webmaster IDG.nl
> Melvyn Sopacua
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Dan Hardiker]

> +
> + Therefore, when dealing with sensative information, there should +
> always be additional methods to decide whether it is a valid +
> session. Sessions are not reliable as a secure +
> authentication mechanism.
> +

So if Im to write an online web-based banking system (either in Java/JSP,
PHP, ASP - whatever)... what method would you suggest that IS secure?


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Stefan Esser]

I do not understand the sense of this whole discussion.
HTTP is a plaintext protocol. So nothing transfered over HTTP can be secure.
No urls, no session no anything.

Stefan


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HUGE memory consumption on fread()

[Wez Furlong]

Potentially, yes, depending on how well your OS handles this,
and how often the script is called and so on.

Under linux, with reasonable amounts of RAM, and assuming that
the script is called frequently enough for the OS not to re-use
the buffers, after the first hit (that maps the file) I'd expect
there to be very little disk i/o (if any) when reading that file.

--Wez.

On 08/14/02, "Andrey Hristov" <[EMAIL PROTECTED]> wrote:
> >
> > Once you've eliminated that problem, I'd suggest that you
> > use readfile() instead of manually looping; readfile should
> > be much kinder to your hardware as it uses mmap, which means
> > that PHP doesn't need to keep allocating small buffers in the loop,
> > and that the OS can potentially share the mapped memory between
> > clients (which makes a lot of sense for you!).
> >
> Does this mean that if I readfile() a file in one script and after it's end
> the same script is invoked it will read from the memory instead of disk i/o?
> 
> Andrey




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Melvyn Sopacua]

Inlined for the list.

Index: reference.xml
===
RCS file: /repository/phpdoc/en/reference/session/reference.xml,v
retrieving revision 1.8
diff -u -r1.8 reference.xml
--- reference.xml   28 Jul 2002 14:04:32 -  1.8
+++ reference.xml   14 Aug 2002 13:58:04 -
@@ -46,6 +46,41 @@
  
 

+   
+Sessions and security
+
+ Using sessions, does not mean, you can be absolutely sure, that
+ the session data can only be viewed by that user. This is impor-
+ tant to keep in mind, when storing and displaying sensative
+ information. When storing data into a session, one should always
+ ask themselves, what the damage is, when somebody else views that
+ information, or how your application is affected when this session
+ is actually somebody else.
+
+
+ For instance, if somebody else takes a session, can he than post
+ a message in a forum, as that user and how big of a problem is that?
+ Or perhaps he can view what the original user was thinking of
+ ordering, because he gets access to that user's shopping cart.
+ Obviously for a flowershop, this is less dramatic, than for a
+ farmacy.
+
+
+ Therefore, when dealing with sensative information, there should
+ always be additional methods to decide whether it is a valid
+ session. Sessions are not reliable as a secure
+ authentication mechanism.
+
+
+ Sessions rely on the session ID, meaning one can 'steal' a session,
+ by stealing the session ID. This can be made harder, by using a cookie
+ specifically a session cookie, but does not in any way make it
+ impossible and still relies on the user closing all
+ browser windows, to expire the session cookie.
+ Besides that, even session cookies can be sniffed on a network or
+ logged by a proxyserver.
+
+   
 
  &reftitle.required;
  &no.requirement;



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PHP-Dev] ZE2 Favour..

[l0t3k]

Andi,
  along the lines of my previous request, is it possible to also export
zend_register_functions ? actually a more general request would be to
evaluate the codebase to determine which functions are likely candidates...

thanks,
l0t3k
BTW - i'll try again to subscribe to the ZE2 mailing list...



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Melvyn Sopacua]

At 15:46 14-8-2002, Alan Knowles wrote:


>Can we not document the real issues about this in the manual, and just say 
>something like
>
>There are security issues in using any type of sessions with HTTP, please 
>read the manual at
>http://www.php.net/en/manual/security.sessions.html
>for a more detail discussion on this subject..


How's the attached for starters.

It's not perfect, as I'm looking for the docbook equivalent of strong,
but concentrate on the text please.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

[Alan Knowles]

Can we not document the real issues about this in the manual, and just 
say something like

There are security issues in using any type of sessions with HTTP, 
please read the manual at
http://www.php.net/en/manual/security.sessions.html
for a more detail discussion on this subject..

regards
Alan

Rasmus Lerdorf wrote:

>As much as I think trans-sid sucks from a performance perspective, what's
>with this comment in php.ini-dist?
>
>; trans sid support is disabled by default.
>; Use of trans sid may risk your users security. It may not be
>; feasible to use this option for some sites. Use this option with caution.
>session.use_trans_sid = 0
>
>What security issue is this referring to?
>
>-Rasmus
>
>
>  
>




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New function request - mysql_info() (patch included)

[Piotr Klaban]

On Wed, Aug 14, 2002 at 02:44:28PM +0200, Jan Lehnardt wrote:
> Hi,
> this version exists in 4.3-dev and will be available in the upcoming 4.3 
> release, however, not in earlier ones. I added it months ago ;)

Thank you very much, this function would help me much.

Regards,

-- 
Piotr Klaban

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] New function request - mysql_info() (patch included)

[Jan Lehnardt]

Hi,
this version exists in 4.3-dev and will be available in the upcoming 4.3 
release, however, not in earlier ones. I added it months ago ;)

Jan
--
Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
Got an old and spare laptop? Please send me a mail.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] New function request - mysql_info() (patch included)

[Piotr Klaban]

Hi,

I enclose the patch for ext/mysql/php_mysql.[ch]
(against PHP version 4.2.2 - for earlier version it also works)
that adds new PHP function - mysql_info().

This function exists in mysql library log time,
and is also defined in the PHP's version of libmysql.

I would like to have acces to this function in PHP,
since mysql_info() is the only way I can check result of
SQL command 'LOAD DATA LOCAL INFILE ...'.

mysql_info() would return a string e.g.:

 Records: 1  Deleted: 0  Skipped: 0  Warnings: 0

I can then know if there were any errors encountered.

Best regards,
(patch is below the signature - `diff -u ...`)

-- 
Piotr Klaban

--- php_mysql.c-origThu Feb 28 09:26:25 2002
+++ php_mysql.c Wed Aug 14 14:09:35 2002
@@ -164,6 +164,7 @@
PHP_FE(mysql_get_proto_info,   
 NULL)
PHP_FE(mysql_get_server_info,  
 NULL)
 #endif
+   PHP_FE(mysql_info, 
+ NULL)
 
/* for downwards compatability */
PHP_FALIAS(mysql,   mysql_db_query, NULL)
@@ -907,6 +908,36 @@
 /* }}} */
 
 #endif
+
+/* {{{ proto string mysql_info([int link_identifier])
+   Returns information about the most recently executed query */
+PHP_FUNCTION(mysql_info)
+{
+   zval **mysql_link;
+   int id;
+   php_mysql_conn *mysql;
+   
+   switch(ZEND_NUM_ARGS()) {
+   case 0:
+   id = MySG(default_link);
+   CHECK_LINK(id);
+   break;
+   case 1:
+   if (zend_get_parameters_ex(1, &mysql_link)==FAILURE) {
+   RETURN_FALSE;
+   }
+   id = -1;
+   break;
+   default:
+   WRONG_PARAM_COUNT;
+   break;
+   }
+   
+   ZEND_FETCH_RESOURCE2(mysql, php_mysql_conn *, mysql_link, id, "MySQL-Link", 
+le_link, le_plink);
+   
+   RETURN_STRING(mysql_info(&mysql->conn), 1);
+}
+/* }}} */
 
 #if MYSQL_VERSION_ID < 4
 /* {{{ proto bool mysql_create_db(string database_name [, int link_identifier])
--- php_mysql.h-origThu Feb 28 09:26:26 2002
+++ php_mysql.h Wed Aug 14 14:09:40 2002
@@ -84,6 +84,7 @@
 PHP_FUNCTION(mysql_get_host_info);
 PHP_FUNCTION(mysql_get_proto_info);
 PHP_FUNCTION(mysql_get_server_info);
+PHP_FUNCTION(mysql_info);
 
 ZEND_BEGIN_MODULE_GLOBALS(mysql)
long default_link;

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HUGE memory consumption on fread()

[Joost Lek]

oh sorry, my previous reply didn't CC the mailing list.

the problem has been solved now, it was indeed the output buffering :(

Wez Furlong wrote:

>On 08/14/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
>  
>
>>Any chance you're using output buffering?
>>
>>
>
>Hopefully you are just using output buffering; check for
>settings in your php.ini or apache configuration such as
>zlib.output_compression, output_buffering, output_handler.
>
>If that doesn't seem to work, there was a memory usage problem
>for remote files - if your files are being retrieved via sockets,
>PHP would not recyle redundant buffer space and you experience similar
>symptoms to what you have described; IIRC the fix for that was in 4.2.
>
>Once you've eliminated that problem, I'd suggest that you
>use readfile() instead of manually looping; readfile should
>be much kinder to your hardware as it uses mmap, which means
>that PHP doesn't need to keep allocating small buffers in the loop,
>and that the OS can potentially share the mapped memory between
>clients (which makes a lot of sense for you!).
>
>--Wez.
> 
>  
>
>>>The problem is a little script we use that puts out files to the user. The 
>>>code used is as follows:
>>>
>>>   if( $fp = fopen( $images_base.$show, "rb" ) ){
>>>   while( !feof( $fp ) ){
>>>   print( fread( $fp, 4096 ) );
>>>   flush();
>>>   }
>>>   }
>>>   fclose($fp);
>>>  
>>>
>
>
>
>  
>



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HUGE memory consumption on fread()

[Andrey Hristov]

>
> Once you've eliminated that problem, I'd suggest that you
> use readfile() instead of manually looping; readfile should
> be much kinder to your hardware as it uses mmap, which means
> that PHP doesn't need to keep allocating small buffers in the loop,
> and that the OS can potentially share the mapped memory between
> clients (which makes a lot of sense for you!).
>
Does this mean that if I readfile() a file in one script and after it's end
the same script is invoked it will read from the memory instead of disk i/o?

Andrey


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HUGE memory consumption on fread()

[Wez Furlong]

On 08/14/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> Any chance you're using output buffering?

Hopefully you are just using output buffering; check for
settings in your php.ini or apache configuration such as
zlib.output_compression, output_buffering, output_handler.

If that doesn't seem to work, there was a memory usage problem
for remote files - if your files are being retrieved via sockets,
PHP would not recyle redundant buffer space and you experience similar
symptoms to what you have described; IIRC the fix for that was in 4.2.

Once you've eliminated that problem, I'd suggest that you
use readfile() instead of manually looping; readfile should
be much kinder to your hardware as it uses mmap, which means
that PHP doesn't need to keep allocating small buffers in the loop,
and that the OS can potentially share the mapped memory between
clients (which makes a lot of sense for you!).

--Wez.
 
> >The problem is a little script we use that puts out files to the user. The 
> >code used is as follows:
> >
> >if( $fp = fopen( $images_base.$show, "rb" ) ){
> >while( !feof( $fp ) ){
> >print( fread( $fp, 4096 ) );
> >flush();
> >}
> >}
> >fclose($fp);



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Melvyn Sopacua]

At 13:37 14-8-2002, Yasuo Ohgaki wrote:


>Improvements, additional descriptions, corrections are welcome
>at any time.

Allright, lemme whip up something.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Errors while building latest snapshot

[Martin Jansen]

While building the latest snapshot, I get the following error during
"make":

ext/standard/info.lo: In function `php_print_info':
/home/martin/source/php4-200208140300/ext/standard/info.c:233:
undefined reference to `iconv_globals'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

My configure options are:

'./configure' \
'--with-apxs=/usr/local/apache/current/bin/apxs' \
'--with-mysql=/usr/local/mysql/current/' \
'--with-pgsql=/usr/local/pgsql/current/' \
'--with-interbase=/opt/interbase/' \
'--with-zlib' \
'--enable-ftp' \
'--with-mcal=/usr/include/mcal/' \
'--with-gettext=/usr/local/' \
'--enable-track-vars' \
'--enable-url-includes' \
'--enable-trans-sid' \
'--enable-sysvsem' \
'--enable-sysvshm' \
'--enable-sockets' \
'--enable-bcmath' \
'--with-config-file-path=/etc' \
'--with-sablot=/usr' \
'--with-xmlrpc' \
'--enable-tokenizer' \
"$@"

Any clues?

-- 
- Martin   Martin Jansen
http://martinjansen.com/

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Bug #10374 [Opn->Bgs]: Depreciated features or not

[Ilia A.]

On August 14, 2002 02:05 am, you wrote:
> Hi Ilia,
>
> One of the compaliant about PHP is things has been
> depreciated/changed w/o proper prior notice. Many
> users are tried with the _bad_ practice AFAIK.

Well depreciation does not mean the functions were removed, it simply means 
that there is an advisory by developers indicating that the function MAY be 
removed at some future point.
Now, if you consider other languages, or libraries like glibc for example, 
they do depreciate functions once in the blue moon. When that is done during 
compilation, unless error level is set to nill you would get a notice from 
the compiler indicating that a certain function has been depriciated and you 
should use function XYZ as an alternative.

Perphaps, we should do the same for PHP?

Ilia


> Therefore, this is valid request :)
>
> I suggest you to open again.
>
> PS: If you are curious, check out how other languages
> are doing and you'll see how poor PHP practice is.


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Jan Lehnardt]

Hi,
On Wed, Aug 14, 2002 at 10:41:24AM +0100, Wez Furlong wrote:
> So, you're suggesting that all external extensions have to be in PECL
> in order for the error message to link to further documentation??
> 
> What about projects like APC/APD? SRM?
> ?
> Do they all have to be hosted on php.net??
hell, no ;) I think it would be nice if there would at least be a pice of
documentation for such  somwhere
on php.net, integrated with all the other docs. And if it is just a name and
link to an external documentation it is sufficient.

Jan
-- 
Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
Got an old and spare laptop? Please send me a mail.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Yasuo Ohgaki]

Melvyn Sopacua wrote:
> 
> We seem to go around in circles :-)
> 
> At 13:08 14-8-2002, you wrote:
> 
>> Melvyn Sopacua wrote:
>>
>>> At 12:04 14-8-2002, Yasuo Ohgaki wrote:
>>>
 Aren't we discussing what method of passing session ID is less
 secure than others?
>>>
>>>
>>> Yes, but I fail to see what it has to do with security.
>>> For instance - I use sessions to store some output that takes a lot 
>>> of time to generate. Why would that be a security risk for anyone?
>>
>>
>> I thought we aren't talking about such case.
>>
>> We should provide appropriate level of protection/security
>> depends of the information/requirements.
>>
>> Using URL based session management is probably ok for web
>> based chat, but not for web based banking.
> 
> 
> My point being: session management can be secure for web-based banking 
> regardless of how it's being delivered. And the opposite also applies: 
> relying on sessions __only__ to provide information is not ok for web 
> based banking, regardless whether it's a cookie or not.
> 
> The comments in the php.ini also implies "as long as I use session 
> cookies I am secure".

Does it?
Any improvements are welcome.

> There are a lot of novice users out there, who are not only new to php, 
> but also to programming, webserving and networking. We should not advise 
> anyone with half of the truth, which can additionally be misinterpreted, 
> but advise them when sessions can be used as the only descision maker 
> and when not.

We have to set a basis somewhere. I'm assuming users know basic
session management issues, even if it's not true for some users.

Improvements, additional descriptions, corrections are welcome
at any time.

--
Yasuo Ohgaki



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Melvyn Sopacua]

We seem to go around in circles :-)

At 13:08 14-8-2002, you wrote:

>Melvyn Sopacua wrote:
>>At 12:04 14-8-2002, Yasuo Ohgaki wrote:
>>>Aren't we discussing what method of passing session ID is less
>>>secure than others?
>>
>>Yes, but I fail to see what it has to do with security.
>>For instance - I use sessions to store some output that takes a lot of 
>>time to generate. Why would that be a security risk for anyone?
>
>I thought we aren't talking about such case.
>
>We should provide appropriate level of protection/security
>depends of the information/requirements.
>
>Using URL based session management is probably ok for web
>based chat, but not for web based banking.

My point being: session management can be secure for web-based banking 
regardless of how it's being delivered. And the opposite also applies: 
relying on sessions __only__ to provide information is not ok for web based 
banking, regardless whether it's a cookie or not.

The comments in the php.ini also implies "as long as I use session cookies 
I am secure".

There are a lot of novice users out there, who are not only new to php, but 
also to programming, webserving and networking. We should not advise anyone 
with half of the truth, which can additionally be misinterpreted, but 
advise them when sessions can be used as the only descision maker and when not.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Yasuo Ohgaki]

Melvyn Sopacua wrote:
> At 12:04 14-8-2002, Yasuo Ohgaki wrote:
>> Aren't we discussing what method of passing session ID is less
>> secure than others?
> 
> 
> Yes, but I fail to see what it has to do with security.
> For instance - I use sessions to store some output that takes a lot of 
> time to generate. Why would that be a security risk for anyone?

I thought we aren't talking about such case.

We should provide appropriate level of protection/security
depends of the information/requirements.

Using URL based session management is probably ok for web
based chat, but not for web based banking.

--
Yasuo Ohgaki



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Wez Furlong]

So, you're suggesting that all external extensions have to be in PECL
in order for the error message to link to further documentation??

What about projects like APC/APD? SRM?
?
Do they all have to be hosted on php.net??

--Wez.


On 08/14/02, "Jan Lehnardt" <[EMAIL PROTECTED]> wrote:
> Hi,
> On Wed, Aug 14, 2002 at 10:09:52AM +0200, Marcus Börger wrote:
> > Then there is only the last argument not spoken about yet:
> > Externally developed extensions.
> and PECL extensions respectively. For external developed extensions I suggest
> putting them into PECL (at least the documentation, if there are license
> issues about the extension's code itself) and for PECL docs I suggest some
> kind of shortcut like: php.net/pecl.function and php.net/pear.function
> while we are at it.
> 
> Jan
> -- 
> Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
> Got an old and spare laptop? Please send me a mail.
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Melvyn Sopacua]

At 12:04 14-8-2002, Yasuo Ohgaki wrote:

>Melvyn Sopacua wrote:
>>Again - security by obscurity. It does not change the fact, that 
>>if($_SESSION['logged_in']) { 'good' } is insecure.
>>Using a trans-sid only makes things more transparent, which is not equal 
>>to less secure in my book, but I know opinions vary in that area.
>
>Who is talking about what kind of infomation should be stored in session?

There are more out there than you can guess.

>Aren't we discussing what method of passing session ID is less
>secure than others?

Yes, but I fail to see what it has to do with security.
For instance - I use sessions to store some output that takes a lot of time 
to generate. Why would that be a security risk for anyone?

>URL based sessin management has more risks than cookie's.
>Please advise people to consider risks :)

It doesn't have any risks if you don't rely on the session ID to be the 
only descision maker.

The advice should go into the manual for the use of sessions and advise the 
above line. The delivery method then is insignificant. One should use 
sessions for storage of information, that otherwise should be looked up in 
a database, or to make usibility advices (you did that, then that, so is it 
this you want?).

If you use sessions for anything that should be 'for this user's eyes 
only', than use additional methods to make sure you are dealing with that user.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Hartmut Holzgraefe]

Dan Hardiker wrote:
> How you can tell a cookie to be stored in RAM rather than on the HDD, Im
> not sure ... but that might mean I need to brush up.

do not set a lifetime and it won't be stored on disk
and live in browser ram until browser is terminated
has been so ever since netscape came up with cookies


> Now this is where the code dev needs an IQ above 3. *Use IP and Browser
> String authentication*
> 
> eg: Load up the session ID given, check the ip and browser string
> (possibly even referrer) and if they dont match, squeel.

IPs might change due tu proxy farms or DHCP leases expiring and
getting renewed with a different IP


-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de/ +49-711-99091-77


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Yasuo Ohgaki]

Dan Hardiker wrote:
>>URL based sessin management has more risks than cookie's.
>>Please advise people to consider risks :)
> 
> 
> but cookies arent always enabled (in my area of deployment 90% dont have
> them enabled) .. and the fact is no matter where the data goes client
> side, the data can still be pulled.

Right. That's why I ask users to enable cookie if I need more security.

I'm not saying we should not use URL based session ID.
Some mobile browsers do not have cookie feature at all.

What I'm insisting is we should let users know what kind
of risks are involved with URL based session.
(Assuming users know issues/risks with session management
with cookie :)

--
Yasuo Ohgaki



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] HUGE memory consumption on fread()

[Zeev Suraski]

Any chance you're using output buffering?

Zeev

At 12:25 14/08/2002, Joost Lek wrote:
>Hello everyone,
>
>I am new to this list, but urgently in need of a solution for a problem i 
>am currently facing.
>First, i'll give a description of my current platform:
>Linux 2.4.18 (origninally slackware, heavily modified)
>apache 1.3.22
>php 4.1.2
>mysql 3.23.46
>(i am aware that these are not the latest versions)
>php is compiled staticly in apache.
>
>The problem is a little script we use that puts out files to the user. The 
>code used is as follows:
>
>if( $fp = fopen( $images_base.$show, "rb" ) ){
>while( !feof( $fp ) ){
>print( fread( $fp, 4096 ) );
>flush();
>}
>}
>fclose($fp);
>
>this works perfectly, until a few days ago. The files served were always 
><2MB, but last week, we needed to use a 100MB file, and now it appears 
>that before starting the output, the httpd process grows up to 108MB+, and 
>then starts output. Offcourse this is not very friendly on our hardware, 
>since multiple clients are sometimes downloading the files, which gives 
>the server loads of up to 100, and the kernel starts killing httpd's to 
>free up memory.
>Does anyone know how i can get httpd to stop 'caching' the entire file? i 
>tried to add the flush() call, it didn't work, i tried the readfile() and 
>fpassthru() calls, same result. I looked through the manuals at php.net 
>and apache.org, no luck. I tried to find a workaround using apache, no luck.
>
>So as my last option i am turning to this list.
>Thank you for your time,
>-- Joost
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Edin Kadribasic]

> Now this is where the code dev needs an IQ above 3. *Use IP and
Browser
> String authentication*

Except you cannot rely on ppl coming from the same IP on every hit.
Many firewalls use several exit IPs (Cisco PIX for example), so
users coming from networks like that would be randomly loged out.

Using session cookies *is* superior choice.

Edin



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Dan Hardiker]

> URL based sessin management has more risks than cookie's.
> Please advise people to consider risks :)

but cookies arent always enabled (in my area of deployment 90% dont have
them enabled) .. and the fact is no matter where the data goes client
side, the data can still be pulled.

I can knock a delphi app which runs in the background pulling the session
id from the pages, no matter where it gets put (ram, hdd, url) just by
intercepting the communication in the [ever so secure] windows layer.

Security in this matter should be taken with a pinch of salt. Some methods
are more flexable (available to more people), some methods take more work
to get the data... but neither is really more secure as the data is still
stored in (effectivly) plain text and is easily locatable.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Yasuo Ohgaki]

Melvyn Sopacua wrote:
> Again - security by obscurity. It does not change the fact, that 
> if($_SESSION['logged_in']) { 'good' } is insecure.
> Using a trans-sid only makes things more transparent, which is not equal 
> to less secure in my book, but I know opinions vary in that area.

Who is talking about what kind of infomation should be stored in session?

Aren't we discussing what method of passing session ID is less
secure than others?

I forgot to mention issues related to SSL.
Anyway, the fact won't change with or without SSL issue.

URL based sessin management has more risks than cookie's.
Please advise people to consider risks :)

--
Yasuo Ohgaki



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Dan Hardiker]

>>This bit confused me slightly ... whats the difference between a
>> Session cookie and a Normal cookie?
>
> It's stored in memory, not on disk.

How you can tell a cookie to be stored in RAM rather than on the HDD, Im
not sure ... but that might mean I need to brush up.

> For the end-user Mr. Priest, this would be considered even 'less
> secure',  because he expects it to be deleted and invalid, but the
> ISP-forced proxy  he's using is logging all headers and Mr. Haxor just
> broke in and used the  session id to get his order form for vanilla
> flavoured condoms.
>
> Now how did that happen? It's a miracle :-)

Now this is where the code dev needs an IQ above 3. *Use IP and Browser
String authentication*

eg: Load up the session ID given, check the ip and browser string
(possibly even referrer) and if they dont match, squeel.

Yes, the browser string and referrer can be faked (although some what
difficultly without a stream dump of the connection, by which point they
have more data than they could hope for... in this case *use https*). The
IP is more difficult to forge... but possible, but I think you catch my
drift.

It does not matter *where* the session id goes client side, it cannot be
trusted. Period.

In order for sessions to work, you must send a session id to the client,
and you must expect to get that back. You have no idea how the client is
storing those cookies and even if you tell the cookie "delete yourself and
never be seen again" (be a ram or hdd cache cookie) you cant rely on that
fact.

If Mr Customer can get in - so can Mr Hacker... simple. Where there is a
will there is a way. All you can guage is the amount that Mr Hacker needs
to know.

At the end of the day - if you want to avoid cookies / session id
insecurities... use a flash interface with xml sockets (blowfish
encrypted).

I wont go into the details here, this has gone far enough off topic.


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Yasuo Ohgaki]

Dan Hardiker wrote:
>>I'm not saying cookie based session is perfectly secure, but
>>it's obvious to me that URL based session is much less secure
>>than cookie one, especially compare to session cookie.
> 
> 
> URL based session-id transferal is not much less secure, because all the
> user has to do is open up their cache and voila, there is the session id.

Again I'm not saying cookie based session is perfectly secure.
I'm pointing it out URL based session is less secure than cookie's.

> 
> I publish e-learning sites to colleges and univercities, and I *still*
> find that 80% of the places we deliver to dont have cookies enabled
> (because of a paranoid sys-admin ... and with the problems reciently found
> in IE, I dont blame them for expecting security holes / bugs, really).

Don't use IE, there are too many security holes :)

> 
> If you are coding a session handler (ontop of the existing php4 set of
> session tools) I would expect the following:
> 
>  * Browser ID checking (and whatever information can be relied upon (in
> certain cases, ip)) to make sure that the session ID hasnt just been cut
> n pasted into an emai
>  * Time based logout *serverside* and an error message to inform the user
> they have been automatically logged out and should they leave their
> terminal unattended / stop working with the site - they should do this
> themselves.

Are you goning to convince people sending URL with active session ID
is diificult? or using same session ID is secure?
Read 1st reply or current php.ini.

Besides, default session save handlers do not check additional
parameters to make session more secure.

> 
> 
>>Session cookie is the best way passing session ID.
>>Second best is normal cookie, then URL/POST method.
> 
> 
> This bit confused me slightly ... whats the difference between a Session
> cookie and a Normal cookie?
> 

Session cookie is cookie with life time 0.
Almost all browser will not save session cookie to file and
it sits in memory. Therefore, it is deleted when browser
is closed.

I've already described how it could be useful to build a
more secure web site with it a little.

I believe there are many articles around that recommends
session cookie over normal cookie. Reading these will help
to understand how URL based session management could be
less secure. Please read articles related for more details.

--
Yasuo Ohgaki



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] HUGE memory consumption on fread()

[Joost Lek]

Hello everyone,

I am new to this list, but urgently in need of a solution for a problem 
i am currently facing.
First, i'll give a description of my current platform:
Linux 2.4.18 (origninally slackware, heavily modified)
apache 1.3.22
php 4.1.2
mysql 3.23.46
(i am aware that these are not the latest versions)
php is compiled staticly in apache.

The problem is a little script we use that puts out files to the user. 
The code used is as follows:

if( $fp = fopen( $images_base.$show, "rb" ) ){
while( !feof( $fp ) ){
print( fread( $fp, 4096 ) );
flush();
}
}
fclose($fp);

this works perfectly, until a few days ago. The files served were always 
<2MB, but last week, we needed to use a 100MB file, and now it appears 
that before starting the output, the httpd process grows up to 108MB+, 
and then starts output. Offcourse this is not very friendly on our 
hardware, since multiple clients are sometimes downloading the files, 
which gives the server loads of up to 100, and the kernel starts killing 
httpd's to free up memory.
Does anyone know how i can get httpd to stop 'caching' the entire file? 
i tried to add the flush() call, it didn't work, i tried the readfile() 
and fpassthru() calls, same result. I looked through the manuals at 
php.net and apache.org, no luck. I tried to find a workaround using 
apache, no luck.

So as my last option i am turning to this list.
Thank you for your time,
-- Joost


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Melvyn Sopacua]

At 11:01 14-8-2002, Dan Hardiker wrote:


>This bit confused me slightly ... whats the difference between a Session
>cookie and a Normal cookie?

It's stored in memory, not on disk.

For the end-user Mr. Priest, this would be considered even 'less secure', 
because he expects it to be deleted and invalid, but the ISP-forced proxy 
he's using is logging all headers and Mr. Haxor just broke in and used the 
session id to get his order form for vanilla flavoured condoms.

Now how did that happen? It's a miracle :-)



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV]php_error_docref

[Gabor Hojtsy]

> >| Erm - good point we cannot find "pecl.function.name" automatically by
> >| docref=NULL. Either pecl must be available by "function.name" or by
> >| just using "name" on php.net. This is also a problem for external
copies
> >| of the manual.
> >
> >PECL, PEAR and other functions won't be available as "function.name" or
> >even "name" from php.net because namespace issues. We have enough URL
> >shortcuts now ( see http://php.net/urlhowto ).
>
> I was just about explaining in detail but now i am more likely to look for
a
> better solution - posting here if i can find any.
> Until i find one pecl and pear extensions will not be able to set
docref=NULL.

If you know that an error is issued from a PECL or a PEAR extension, than
it's equally easy to have a URL for php.net/pear.func or pear.php.net/func

Goba



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Marcus Börger]

At 10:57 14.08.2002, Gabor Hojtsy wrote:
> > > Then there is only the last argument not spoken about yet:
> > > Externally developed extensions.
> >and PECL extensions respectively. For external developed extensions I
>suggest
> >putting them into PECL (at least the documentation, if there are license
> >issues about the extension's code itself) and for PECL docs I suggest some
> >kind of shortcut like: php.net/pecl.function and php.net/pear.function
> >while we are at it.
>
>| Erm - good point we cannot find "pecl.function.name" automatically by
>| docref=NULL. Either pecl must be available by "function.name" or by
>| just using "name" on php.net. This is also a problem for external copies
>| of the manual.
>
>PECL, PEAR and other functions won't be available as "function.name" or
>even "name" from php.net because namespace issues. We have enough URL
>shortcuts now ( see http://php.net/urlhowto ).
>
>Goba

I was just about explaining in detail but now i am more likely to look for a
better solution - posting here if i can find any.

Until i find one pecl and pear extensions will not be able to set docref=NULL.

marcus


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP_SELF confusion (errata)

[Piotr Klaban]

On Tue, Aug 13, 2002 at 03:54:58PM +0200, Piotr Klaban wrote:
> and if I call http://server/dir/file.php?q=1, the result is:
> 
>Apache module  PHP CGI
> PHP_SELF   /dir/file.php/path-info/dir/file.php

I am sorry it is a mistake, it should be:


and if I call http://server/dir/file.php?q=1, the result is:

   Apache module  PHP CGI
PHP_SELF   /dir/file.php  /dir/file.php


-- 
Piotr Klaban

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Melvyn Sopacua]

At 10:58 14-8-2002, Yasuo Ohgaki wrote:

>Hi,
>
>I guess you missed some points :)

Nope :-)

>Melvyn Sopacua wrote:
>>At 08:18 14-8-2002, Yasuo Ohgaki wrote:
>>
>>>Rasmus Lerdorf wrote:
>>>
As much as I think trans-sid sucks from a performance perspective, what's
with this comment in php.ini-dist?
; trans sid support is disabled by default.
; Use of trans sid may risk your users security. It may not be
; feasible to use this option for some sites. Use this option with caution.
session.use_trans_sid = 0
What security issue is this referring to?
>>>
>>>
>>>One of security risk is sending URL that contains
>>>active session ID to others.
>>
>>Using sessions as the only method for authentication en permission grants 
>>is a security risk, regardless of the client-side storage of the session 
>>ID. It's easy enough to send a cookie to somebody else.
>
>Sending cookie file or find out cookie value and send it via email
>is as easy as sending URL with session id?
>
>Will normal users notice session id in URL and get rid of it before
>send it to thier friends?

Again - security by obscurity. It does not change the fact, that 
if($_SESSION['logged_in']) { 'good' } is insecure.
Using a trans-sid only makes things more transparent, which is not equal to 
less secure in my book, but I know opinions vary in that area.


>>>Another is storing URL that contains session
>>>ID to history. Computer may be public one.
>>>User may access server with the same session ID
>>>always. etc
>>
>>If this is a public computer (I think you mean like in an internet cafe 
>>or library) the same applies to cookies, only then it's less obvious, so 
>>I'd say trans-sid is more secure.
>
>Session ID in URL can never be as secure as cookie.
>
>Using the same session id forever is secure? or asking users to close 
>browser is as easy as asking find and delete history/bookmark? (Obviously, 
>I'm assuming use of session cookie here)

Again - this does __not__ change the fact, that sensative information 
should not be stored in sessions, cause that's the real problem.

And if it's not sensative information that's stored, who cares that 
somebody else uses the session id.


Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Dan Hardiker]

> I'm not saying cookie based session is perfectly secure, but
> it's obvious to me that URL based session is much less secure
> than cookie one, especially compare to session cookie.

URL based session-id transferal is not much less secure, because all the
user has to do is open up their cache and voila, there is the session id.

I publish e-learning sites to colleges and univercities, and I *still*
find that 80% of the places we deliver to dont have cookies enabled
(because of a paranoid sys-admin ... and with the problems reciently found
in IE, I dont blame them for expecting security holes / bugs, really).

If you are coding a session handler (ontop of the existing php4 set of
session tools) I would expect the following:

 * Browser ID checking (and whatever information can be relied upon (in
certain cases, ip)) to make sure that the session ID hasnt just been cut
n pasted into an emai
 * Time based logout *serverside* and an error message to inform the user
they have been automatically logged out and should they leave their
terminal unattended / stop working with the site - they should do this
themselves.

Security is just an illusion in the end anyway - its the user that is the
prime culprit of security evasion, and the end point is: no matter how you
do it - you have to get a unique session key / id from the client back to
the server in some way. Because this is stored on the client (either as
cookie, url or in the outputed code somewhere), it will always have a
flaw.

> Session cookie is the best way passing session ID.
> Second best is normal cookie, then URL/POST method.

This bit confused me slightly ... whats the difference between a Session
cookie and a Normal cookie?

-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV]php_error_docref

[Gabor Hojtsy]

> > Then there is only the last argument not spoken about yet:
> > Externally developed extensions.
>and PECL extensions respectively. For external developed extensions I
suggest
>putting them into PECL (at least the documentation, if there are license
>issues about the extension's code itself) and for PECL docs I suggest some
>kind of shortcut like: php.net/pecl.function and php.net/pear.function
>while we are at it.

| Erm - good point we cannot find "pecl.function.name" automatically by
| docref=NULL. Either pecl must be available by "function.name" or by
| just using "name" on php.net. This is also a problem for external copies
| of the manual.

PECL, PEAR and other functions won't be available as "function.name" or
even "name" from php.net because namespace issues. We have enough URL
shortcuts now ( see http://php.net/urlhowto ).

Goba



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Jan Lehnardt]

Hi,
On Wed, Aug 14, 2002 at 10:25:40AM +0200, Marcus Börger wrote:
> 
> Erm - good point we cannot find "pecl.function.name" automatically by
> docref=NULL. Either pecl must be available by "function.name" or by
> just using "name" on php.net. This is also a problem for external copies
> of the manual.
erm, what?

Jan
-- 
Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
Got an old and spare laptop? Please send me a mail.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Yasuo Ohgaki]

Hi,

I guess you missed some points :)

Melvyn Sopacua wrote:
> At 08:18 14-8-2002, Yasuo Ohgaki wrote:
> 
>> Rasmus Lerdorf wrote:
>>
>>> As much as I think trans-sid sucks from a performance perspective, 
>>> what's
>>> with this comment in php.ini-dist?
>>> ; trans sid support is disabled by default.
>>> ; Use of trans sid may risk your users security. It may not be
>>> ; feasible to use this option for some sites. Use this option with 
>>> caution.
>>> session.use_trans_sid = 0
>>> What security issue is this referring to?
>>
>>
>> One of security risk is sending URL that contains
>> active session ID to others.
> 
> 
> Using sessions as the only method for authentication en permission 
> grants is a security risk, regardless of the client-side storage of the 
> session ID. It's easy enough to send a cookie to somebody else.

Sending cookie file or find out cookie value and send it via email
is as easy as sending URL with session id?

Will normal users notice session id in URL and get rid of it before
send it to thier friends?

> 
>> Another is storing URL that contains session
>> ID to history. Computer may be public one.
>> User may access server with the same session ID
>> always. etc
> 
> 
> If this is a public computer (I think you mean like in an internet cafe 
> or library) the same applies to cookies, only then it's less obvious, so 
> I'd say trans-sid is more secure.

Session ID in URL can never be as secure as cookie.

Using the same session id forever is secure? or asking users to close 
browser is as easy as asking find and delete history/bookmark? 
(Obviously, I'm assuming use of session cookie here)

> The 'always' factor depends on the session timeout. 
> 

Not only server side timeout, but also client side timeout is
very important. That's the one of the reason why session cookie
is recommended. Users can easily control life time of cookie.
We also sure most users will close their browser sometimes.
It's easy to ask users to close browser also.

I'm not saying cookie based session is perfectly secure, but
it's obvious to me that URL based session is much less secure
than cookie one, especially compare to session cookie.

Session cookie is the best way passing session ID.
Second best is normal cookie, then URL/POST method.

--
Yasuo Ohgaki




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Marcus Börger]

At 10:15 14.08.2002, Jan Lehnardt wrote:
>Hi,
>On Wed, Aug 14, 2002 at 10:09:52AM +0200, Marcus Börger wrote:
> > Then there is only the last argument not spoken about yet:
> > Externally developed extensions.
>and PECL extensions respectively. For external developed extensions I suggest
>putting them into PECL (at least the documentation, if there are license
>issues about the extension's code itself) and for PECL docs I suggest some
>kind of shortcut like: php.net/pecl.function and php.net/pear.function
>while we are at it.

Erm - good point we cannot find "pecl.function.name" automatically by
docref=NULL. Either pecl must be available by "function.name" or by
just using "name" on php.net. This is also a problem for external copies
of the manual.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Jan Lehnardt]

Hi,
On Wed, Aug 14, 2002 at 10:09:52AM +0200, Marcus Börger wrote:
> Then there is only the last argument not spoken about yet:
> Externally developed extensions.
and PECL extensions respectively. For external developed extensions I suggest
putting them into PECL (at least the documentation, if there are license
issues about the extension's code itself) and for PECL docs I suggest some
kind of shortcut like: php.net/pecl.function and php.net/pear.function
while we are at it.

Jan
-- 
Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
Got an old and spare laptop? Please send me a mail.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Marcus Börger]

At 10:03 14.08.2002, Jan Lehnardt wrote:
>Hi,
>On Tue, Aug 13, 2002 at 05:26:17PM +0200, Marcus Börger wrote:
> > At 17:05 13.08.2002, Dan Kalowsky wrote:
> > >On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
> > >
> > > > >2) Can we please remove the 
> "http://www.php.net/manual/en/blahblahblah";
> > > > >style of use for this?  It will tend to force users into one 
> language or
> > > > >another, and not make PHP as friendly/usable to other languages.
> > > >
> > > > NO! First you can simply set docref_root in your ini to point to 
> your local
> > > > copy of the manual in whatever language and Second it is a problem of
> > > > the php website. It should automatically redirect from
> > > > php.net/function.
> > > > to php.net/manual//.php
> > >
> > >I'm not sure I see the point still.  What I'm proposing is not allowing:
> > >
> > >php_error_docref("http://www.php.net/manual/en/function.fopen"; TSRMLS_CC,
> > >E_WARNING, "Spongebob Square Pants rules");
> >
> > The point is to be able to direct to external sites not on php.net! For
> > example
> > when a function is just a wrapper around a library then you can use the
> > absolute
> > form of the docref parameter ("http://") to point to the library's
> > website.
>
>if the PHP function is 'just a wrapper' the manual (at least should) contain
>a link to external documentation (if available). I see nothing wrong with
>limiting linking just to .php.net

Then there is only the last argument not spoken about yet:
Externally developed extensions.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] php_error_docref

[Jan Lehnardt]

Hi,
On Tue, Aug 13, 2002 at 05:26:17PM +0200, Marcus Börger wrote:
> At 17:05 13.08.2002, Dan Kalowsky wrote:
> >On Tue, 13 Aug 2002, Marcus [iso-8859-1] Börger wrote:
> >
> > > >2) Can we please remove the "http://www.php.net/manual/en/blahblahblah";
> > > >style of use for this?  It will tend to force users into one language or
> > > >another, and not make PHP as friendly/usable to other languages.
> > >
> > > NO! First you can simply set docref_root in your ini to point to your local
> > > copy of the manual in whatever language and Second it is a problem of
> > > the php website. It should automatically redirect from
> > > php.net/function.
> > > to php.net/manual//.php
> >
> >I'm not sure I see the point still.  What I'm proposing is not allowing:
> >
> >php_error_docref("http://www.php.net/manual/en/function.fopen"; TSRMLS_CC,
> >E_WARNING, "Spongebob Square Pants rules");
> 
> The point is to be able to direct to external sites not on php.net! For 
> example
> when a function is just a wrapper around a library then you can use the 
> absolute
> form of the docref parameter ("http://") to point to the library's 
> website.

if the PHP function is 'just a wrapper' the manual (at least should) contain
a link to external documentation (if available). I see nothing wrong with
limiting linking just to .php.net

Jan
-- 
Q: Thank Jan? A: http://geschenke.an.dasmoped.net/
Got an old and spare laptop? Please send me a mail.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: trans-sid warning?

[Melvyn Sopacua]

Hi,

At 08:18 14-8-2002, Yasuo Ohgaki wrote:

>Rasmus Lerdorf wrote:
>>As much as I think trans-sid sucks from a performance perspective, what's
>>with this comment in php.ini-dist?
>>; trans sid support is disabled by default.
>>; Use of trans sid may risk your users security. It may not be
>>; feasible to use this option for some sites. Use this option with caution.
>>session.use_trans_sid = 0
>>What security issue is this referring to?
>
>One of security risk is sending URL that contains
>active session ID to others.

Using sessions as the only method for authentication en permission grants 
is a security risk, regardless of the client-side storage of the session 
ID. It's easy enough to send a cookie to somebody else.

>Another is storing URL that contains session
>ID to history. Computer may be public one.
>User may access server with the same session ID
>always. etc

If this is a public computer (I think you mean like in an internet cafe or 
library) the same applies to cookies, only then it's less obvious, so I'd 
say trans-sid is more secure.

The 'always' factor depends on the session timeout. If there is no session 
with that id, the session ID is worthless.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php