I want to translate the documentation to hungarian language. Goba sad me, that i need
a CVS account
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
The PHP manual says it is the developer's job to ensure PHP sessions cannot
be stolen or "fixed" (this is called Session Fixation).
To minimise the risk of session fixation, I wrote a patch for PHP-4.3.5 (I
can port it for the other versions too - just ask...), that makes (almost)
sure the
Hello,
sure the current user IS the session creator. It is based on client IP
addresses.
A legal user can have multiple IP addresses at the same time. This can
have several reasons...
for example
a) ISP did disconnect him inbetween clicks
b) he is using a proxy but for the https part of your
On Wed, 2004-04-07 at 09:56, inodes wrote:
> Hello,
>
> The PHP manual says it is the developer's job to ensure PHP sessions cannot
> be stolen or "fixed" (this is called Session Fixation).
>
> To minimise the risk of session fixation, I wrote a patch for PHP-4.3.5 (I
> can port it for the other
I agree with all your arguments: the IP-base solution IS NOT perfect.
It is not generic enough to be implemented in world-wide application, but it
can be useuful for intranet or extranets. That's to say cases when you know
the infrastructure used by the clients to connect to your server support
th
On Apr 7, 2004, at 10:17 AM, Robert Cummings wrote:
On Wed, 2004-04-07 at 09:56, inodes wrote:
Hello,
The PHP manual says it is the developer's job to ensure PHP sessions
cannot
be stolen or "fixed" (this is called Session Fixation).
To minimise the risk of session fixation, I wrote a patch for
> It is not generic enough to be implemented in world-wide application, but it
> can be useuful for intranet or extranets. That's to say cases when you know
> the infrastructure used by the clients to connect to your server support
> this strategy.
If you want this feature, implement it in you
Sasha suggests me to implement these checkings in my script: IMHO that's not
the good strategy.
You guys are probably good programmers, but my experience shows me that the
"standard" PHP developper is not aware of security problems or he/she has
not the time to finalize the scripts (time is money.
While I like that your patch can be turned on and off in the INI, this
sounds much more like an application-level problem, and thus should be
implemented at the application level.
MHO.
S
inodes wrote:
I agree with all your arguments: the IP-base solution IS NOT perfect.
It is not generic enou
I also would add that from experience using IP addresses to validate
sessions does not work for any internet application.
It is not generic enough to be implemented in world-wide application, but it
can be useuful for intranet or extranets. That's to say cases when you know
the infrastructure use
Inodes wrote:
You guys are probably good programmers, but my experience shows me that the
"standard" PHP developper is not aware of security problems or he/she has
not the time to finalize the scripts (time is money...).
The problem with your patch is twofold:
1) It breaks for some users under rare
Wez Furlong wrote:
I'd like to merge ext/yaz source (not config.m4) from HEAD to PHP4
branch (which I assume would be in 4.3.6, when out). That's bad carma,
right?
Unless it fixes some critical major bad bugs, no, you're not allowed
to merge from HEAD.
FWIW, the YAZ API in PHP5 is comple
--- Christian Schneider <[EMAIL PROTECTED]> wrote:
> I decided to say "If X knows the session ID of User A then he _is_ A".
This isn't a good approach, but you can bring this up on php-general to
discuss why. I'm sure plenty of people will be happy to discuss it.
> (Side note: I use my own random
On Wed, 7 Apr 2004, Adam Dickmeiss wrote:
> Worth considering. That means taking it out from php-src as well, I suppose.
Yes
> Should documentation move away from phpdoc also?
No :)
regards,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
On Wed, 7 Apr 2004, Chris Shiflett wrote:
> --- Christian Schneider <[EMAIL PROTECTED]> wrote:
> > I decided to say "If X knows the session ID of User A then he _is_ A".
>
> This isn't a good approach, but you can bring this up on php-general to
> discuss why. I'm sure plenty of people will be hap
Derick Rethans wrote:
PHP's generated from remote ID, process id, time and some randomness;
and then MD5'ed. That's 'better' then your random/MD5 based approach as
it's even less likely to result in collisions.
How can you tell without knowing what my source of random data is? And
no, I'm not worr
maybe its possible for the parser to ignore public/private/protected
declarations on __call() (& also __set(), __get()) methods, given PHP
forgiving nature/image (at least that is my impression).
at the very least spare php-general a ton of emails by mentioning it
prominently in the documentati
On Apr 7, 2004, at 9:28 PM, Jochem Maas wrote:
maybe its possible for the parser to ignore public/private/protected
declarations on __call() (& also __set(), __get()) methods, given PHP
forgiving nature/image (at least that is my impression).
The whole point of PPP is to not be forgiving or per
Sean Coates wrote:
While I like that your patch can be turned on and off in the INI, this
sounds much more like an application-level problem, and thus should be
implemented at the application level.
Loads of people have actually put stuff out that does this...
^
|
Other tests cou
On Apr 7, 2004, at 9:48 PM, Jochem Maas wrote:
Sean Coates wrote:
While I like that your patch can be turned on and off in the INI,
this sounds much more like an application-level problem, and thus
should be implemented at the application level.
Loads of people have actually put stuff out that
George Schlossnagle wrote:
On Apr 7, 2004, at 9:28 PM, Jochem Maas wrote:
maybe its possible for the parser to ignore public/private/protected
declarations on __call() (& also __set(), __get()) methods, given PHP
forgiving nature/image (at least that is my impression).
The whole point of PPP
Jochem Maas wrote:
I'm happy to just remove the P and add it again if ever that becomes an
option.
Or go for the simpler option: Just don't use P.
An addition to the documentation of __call saying that it has to be
public makes sense though. The meaning of PPP on __call would be
confusing anywa
Good day.
I'm one of interpreters who translate the documentation to Russian.
Several parts (security/*, pcre/*) are already translated and
commited, some parts (f.e. features/*) are in progress now.
I need CVS-account to the fork phpdoc-ru/ to add new translations and
to renew completed.
>> I
Derick Rethans wrote:
On Wed, 7 Apr 2004, Adam Dickmeiss wrote:
Worth considering. That means taking it out from php-src as well, I suppose.
Yes
Should documentation move away from phpdoc also?
No :)
regards,
Derick
I intent to move it, when time permits. After Easter. It sho
Frank M. Kromann wrote:
> + WScript.StdOut.WriteLine(fc.item());
This looks like debugging code to me. Shouldn't it be removed?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwickl
Maintaining a package at PEAR
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
26 matches
Mail list logo
