Re: [PHP-DEV] Re: Re: Session patch

[mlwmohawk]

>> Should php create the session id, or should the session handler? 
> 
> PHP should.  Here is something to think about. 
> 
> It is hard to generate hard to guess session ids.  PHP has 
> various internal entropy sources and can read from system 
> provided entropy sources as well.  That gives PHP users an 
> adequate level of pseudo-random session ids. 
 
Perhaps, and here is something to think about, pseudo-random is not what the developer 
wants as a session 
ID. 
 
> 
> If storage handlers would generate their own session ids, 
> they would have to reimplement all of the above.  Because 
> that it is an uneasy task, many (most) storage handlers will 
> get it wrong.  And which project is the most likely to be 
> blamed for that?  PHP, because it would give too much control 
> to storage handlers. 
 
The storage handlers need not calculate the session id. In fact, most will not. 
However, if they have a 
real purpose in needing to generate session ids, that capability is provided in the 
patch. The srm 
project and msession project will benefit from this capability. 
 
> 
> Currently, session ids have a defined format which our users 
> rely on.  If storage handlers control the format, they might 
> choose to change it for some odd reason.  Thus our users' 
> deployed applications might break out of the blue. 
 
That is the risk with any session handler, regardless of ID format. That is the risk 
of providing an 
extension API. If the session handler does not work correctly, it will break 
applications. Saying "no you 
can't do that because we'll look bad" is a pretty lame excuse for reducing flexibility 
that extension 
developers are asking for. 
 
> 
> Up to now, noone has claimed that the session module ever 
> produced collisions among session ids.  If the opposite can 
> be shown, I'd favor fixing session id generation in one 
> place, instead of the X storage handlers in the wild. 
 
It isn't just about session collisions. It is about having the extension create he 
session and ID that 
goes with it. 
 
The argument as I see it is this: What harm does it do to apply the patch? Are there 
any functional 
reasons why this won't work? If you want to insult the extension developers by saying 
we will do it wrong, 
I take offense to that. Who are you to critisize the people that try to contribute to 
PHP? That seems 
very rude. 
 


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

Re: [PHP-DEV] Re: Re: Session patch

[Sascha Schumann]

> Perhaps, and here is something to think about, pseudo-random is
> not what the developer wants as a session ID.

Well, provided that there is a device which captures white
noise, you can also get real random session ids with the
current code.

> The storage handlers need not calculate the session id. In
> fact, most will not. However, if they have a real purpose in
> needing to generate session ids, that capability is provided in

What purpose?  So far, I have not seen any reason why they
would want to do generate their own session ids.  If there
are any, please share your wisdom.

> > Currently, session ids have a defined format which our users
> > rely on.  If storage handlers control the format, they might
> > choose to change it for some odd reason.  Thus our users'
> > deployed applications might break out of the blue.
>
> That is the risk with any session handler, regardless of ID
> format. That is the risk of providing an extension API. If the
> session handler does not work correctly, it will break
> applications. Saying "no you can't do that because we'll look
> bad" is a pretty lame excuse for reducing flexibility that
> extension developers are asking for.

That reply appears to be unrelated to the quoted paragraph.

> It isn't just about session collisions. It is about having the
> extension create he session and ID that goes with it.

Well, I'd welcome a patch which enables storage handlers to
validate/invalidate newly created session ids.

Based on the reasons you have given so far, I don't see any
advantage for users in letting storage handlers generate
session ids.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg



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

Re: [PHP-DEV] Re: Re: Session patch

[mlwmohawk]

Why is it you do not wish the session save handlers to be able to generare their own 
session IDs? The 
patch does not break any save handlers, but adds a lot more flexibility to the session 
system. 
 
A pseudo-random number may not be what is desired. I may want the session id to be the 
user's name. I 
may want it to be their IP address. Who knows? That is the point of flexibility, 
choice. 
 
In a web site that does not use only PHP, maybe a save handler may need to query 
anoher system to get 
the session ID from that. There are lots of reason to commit the patch. And only your 
fear that session 
hander writers will (in your words) "get it wrong." (Which, by the way, is quite 
insulting, you should try 
to respect the people who contribute.) 
 
Your position is valid only if you assume eeryone wants the session ID to have the 
same properties that 
you do. If that is the case, why have extensions at all, PHP should just be what it 
is, because no one 
should want anything different. Hell, why should it be open source, someone can change 
it and "get it 
wrong!" Make it closed source, that will fix everything.  
 
If the patch does not break anything, and to my knowledge it doesn't, why not add it? 
What is the harm? 
The question of "should" has already been answered by a few developers. It should now 
be a technical 
discussion of the impact on the code as a whole, and there should be none beyond 
adding functionality. 
 
 
>> Perhaps, and here is something to think about, pseudo-random is  
>> not what the developer wants as a session ID.  
>   
> Well, provided that there is a device which captures white  
> noise, you can also get real random session ids with the  
> current code.  
>   
>> The storage handlers need not calculate the session id. In  
>> fact, most will not. However, if they have a real purpose in  
>> needing to generate session ids, that capability is provided in  
>   
> What purpose?  So far, I have not seen any reason why they  
> would want to do generate their own session ids.  If there  
> are any, please share your wisdom.  
>   
>> > Currently, session ids have a defined format which our users  
>> > rely on.  If storage handlers control the format, they might  
>> > choose to change it for some odd reason.  Thus our users'  
>> > deployed applications might break out of the blue.  
>>  
>> That is the risk with any session handler, regardless of ID  
>> format. That is the risk of providing an extension API. If the  
>> session handler does not work correctly, it will break  
>> applications. Saying "no you can't do that because we'll look  
>> bad" is a pretty lame excuse for reducing flexibility that  
>> extension developers are asking for.  
>   
> That reply appears to be unrelated to the quoted paragraph.  
>   
>> It isn't just about session collisions. It is about having the  
>> extension create he session and ID that goes with it.  
>   
> Well, I'd welcome a patch which enables storage handlers to  
> validate/invalidate newly created session ids.  
>   
> Based on the reasons you have given so far, I don't see any  
> advantage for users in letting storage handlers generate  
> session ids.  
>   
> - Sascha Experience IRCG  
>   http://schumann.cx/http://schumann.cx/ircg  
>   
>   
>   
> --   
> 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: Re: Session patch

[Stefan Esser]

Hi,

I have not followed the discussion, but its nonsense to force people to use
PHP generated session IDs. Its an argument against using PHP.
There are several situations where it is not possible to let PHP generate
the session ids. Especially if you use stuff like the Sevenval FIT or HIT
technology which makes use of hostnames to contain the session ids.
Stuff like this is needed to track f.e. shockwave or flash content.

Stefan

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

Re: [PHP-DEV] Re: Re: Session patch

[Egon Schmid]

No, I don´t read such nonsense patents.

-Egon

- Original Message -
From: "Stefan Esser" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 28, 2002 7:35 PM
Subject: Re: [PHP-DEV] Re: Re: Session patch


> Hi,
>
> I have not followed the discussion, but its nonsense to force
people to use
> PHP generated session IDs. Its an argument against using PHP.
> There are several situations where it is not possible to let PHP
generate
> the session ids. Especially if you use stuff like the Sevenval FIT
or HIT
> technology which makes use of hostnames to contain the session
ids.
> Stuff like this is needed to track f.e. shockwave or flash
content.
>
> Stefan
>
> --
> 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] Re: Re: Session patch

[derick]

On Thu, 28 Mar 2002, Egon Schmid wrote:

> No, I don´t read such nonsense patents.

What patents are you talking about? There is no single word about patents 
in this email...

Derick

> - Original Message -
> From: "Stefan Esser" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, March 28, 2002 7:35 PM
> Subject: Re: [PHP-DEV] Re: Re: Session patch
> 
> 
> > Hi,
> >
> > I have not followed the discussion, but its nonsense to force
> people to use
> > PHP generated session IDs. Its an argument against using PHP.
> > There are several situations where it is not possible to let PHP
> generate
> > the session ids. Especially if you use stuff like the Sevenval FIT
> or HIT
> > technology which makes use of hostnames to contain the session
> ids.
> > Stuff like this is needed to track f.e. shockwave or flash
> content.
> >
> > Stefan
> >
> > --
> > 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: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

RE: [PHP-DEV] Re: Re: Session patch

[Robinson, Mike]

Title: RE: [PHP-DEV] Re: Re: Session patch





Stefan Esser writes:
> Hi,
> 
> I have not followed the discussion, but its nonsense to force 
> people to use
> PHP generated session IDs. Its an argument against using PHP.


I don't think so.


> There are several situations where it is not possible to let 
> PHP generate
> the session ids. Especially if you use stuff like the 
> Sevenval FIT or HIT
> technology which makes use of hostnames to contain the session ids.
> Stuff like this is needed to track f.e. shockwave or flash content.


There are millions of reasons why we _would_ want php to use its own
IDs and let others implement solutions in user space. Each one sits
a keyboard and has WTF as their middle initials.



Mike Robinson
IT/Developer - Torstar Media Group Television
Phone: 416.945.8786 Fax: 416.869.4566
Email: [EMAIL PROTECTED]




To find out more about what we can do for you, please visit us at:
http://www.tmgtv.ca/ and http://www.thestar.com/ 



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

RE: [PHP-DEV] Re: Re: Session patch

[derick]

On Thu, 28 Mar 2002, Robinson, Mike wrote:

> Stefan Esser writes:
> > Hi,
> > 
> > I have not followed the discussion, but its nonsense to force 
> > people to use
> > PHP generated session IDs. Its an argument against using PHP.
> 
> I don't think so.
> 
> > There are several situations where it is not possible to let 
> > PHP generate
> > the session ids. Especially if you use stuff like the 
> > Sevenval FIT or HIT
> > technology which makes use of hostnames to contain the session ids.
> > Stuff like this is needed to track f.e. shockwave or flash content.
> 
> There are millions of reasons why we _would_ want php to use its own
> IDs and let others implement solutions in user space. Each one sits
> a keyboard and has WTF as their middle initials.

I have no idea why you think there is a WTF here. Developpers who use 
software like msession, or SRM, will know that the session id has not the 
standard session format. It also has totally nothing to do with userspace.

Derick

---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

RE: [PHP-DEV] Re: Re: Session patch

[mlwmohawk]

> Stefan Esser writes: 
>> Hi, 
>>  
>> I have not followed the discussion, but its nonsense to force  
>> people to use 
>> PHP generated session IDs. Its an argument against using PHP. 
>  
> I don't think so. 
>  
>> There are several situations where it is not possible to let  
>> PHP generate 
>> the session ids. Especially if you use stuff like the  
>> Sevenval FIT or HIT 
>> technology which makes use of hostnames to contain the session ids. 
>> Stuff like this is needed to track f.e. shockwave or flash content. 
>  
> There are millions of reasons why we _would_ want php to use its own 
> IDs and let others implement solutions in user space. Each one sits a 
> keyboard and has WTF as their middle initials. 
 
I can't tell if you are for or against the patch that was submited. The patch, in no 
way, removes PHP's 
session ID creation code. I merely makes it optional for extensions which see a need 
to have a different 
session ID strategy. 
 
>  
>  
> Mike Robinson 
> IT/Developer - Torstar Media Group Television 
> Phone: 416.945.8786 Fax: 416.869.4566 
> Email: [EMAIL PROTECTED] 


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

RE: [PHP-DEV] Re: Re: Session patch

[Robinson, Mike]

Title: RE: [PHP-DEV] Re: Re: Session patch





I went back and re-read the thread after Derek's note.
I misunderstood the purpose of the patch.


Mike Robinson
IT/Developer - Torstar Media Group Television
Phone: 416.945.8786 Fax: 416.869.4566
Email: [EMAIL PROTECTED]



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 28, 2002 3:14 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Re: Re: Session patch
> 
> 
> > Stefan Esser writes: 
> >> Hi, 
> >>  
> >> I have not followed the discussion, but its nonsense to force  
> >> people to use 
> >> PHP generated session IDs. Its an argument against using PHP. 
> >  
> > I don't think so. 
> >  
> >> There are several situations where it is not possible to let  
> >> PHP generate 
> >> the session ids. Especially if you use stuff like the  
> >> Sevenval FIT or HIT 
> >> technology which makes use of hostnames to contain the 
> session ids. 
> >> Stuff like this is needed to track f.e. shockwave or flash 
> content. 
> >  
> > There are millions of reasons why we _would_ want php to 
> use its own 
> > IDs and let others implement solutions in user space. Each 
> one sits a 
> > keyboard and has WTF as their middle initials. 
>  
> I can't tell if you are for or against the patch that was 
> submited. The patch, in no way, removes PHP's 
> session ID creation code. I merely makes it optional for 
> extensions which see a need to have a different 
> session ID strategy. 
>  
> >  
> >  
> > Mike Robinson 
> > IT/Developer - Torstar Media Group Television 
> > Phone: 416.945.8786 Fax: 416.869.4566 
> > Email: [EMAIL PROTECTED] 
> 




To find out more about what we can do for you, please visit us at:
http://www.tmgtv.ca/ and http://www.thestar.com/ 



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

Re: [PHP-DEV] Re: Re: Session patch

[Egon Schmid]

Have a look at www.sevenval.com. Sorry everything is German. If you
poke around with your browser and watch the URLs you can easily
regocnize what I mean. The generated URLs are patents. Please ask
Hartmut for more details.

-Egon

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Egon Schmid" <[EMAIL PROTECTED]>
Cc: "Stefan Esser" <[EMAIL PROTECTED]>; "PHP Developers Mailing
List" <[EMAIL PROTECTED]>
Sent: Thursday, March 28, 2002 8:32 PM
Subject: Re: [PHP-DEV] Re: Re: Session patch


> On Thu, 28 Mar 2002, Egon Schmid wrote:
>
> > No, I don´t read such nonsense patents.
>
> What patents are you talking about? There is no single word about
patents
> in this email...
>
> Derick
>
> > - Original Message -
> > From: "Stefan Esser" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Thursday, March 28, 2002 7:35 PM
> > Subject: Re: [PHP-DEV] Re: Re: Session patch
> >
> >
> > > Hi,
> > >
> > > I have not followed the discussion, but its nonsense to force
> > people to use
> > > PHP generated session IDs. Its an argument against using PHP.
> > > There are several situations where it is not possible to let
PHP
> > generate
> > > the session ids. Especially if you use stuff like the Sevenval
FIT
> > or HIT
> > > technology which makes use of hostnames to contain the session
> > ids.
> > > Stuff like this is needed to track f.e. shockwave or flash
> > content.
> > >
> > > Stefan
> > >
> > > --
> > > 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: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> --
-
>
>


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

Re: [PHP-DEV] Re: Re: Session patch

[Stefan Esser]

Hi,

> Have a look at www.sevenval.com. Sorry everything is German. If you

Hmm yeah but if your browser is really not able to do proper content
negotiation, there is still an "english" button in the right lower edge of
the page...

> regocnize what I mean. The generated URLs are patents.
> Please ask Hartmut for more details.

Ask more about what? That this stuff is patented is funny, because it shows
how idiotic the european law is, but thats another story. Anyway I wonder
what Hartmut can tell me about Sevenval that I don't already know :)

Stefan


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

Re: [PHP-DEV] Re: Re: Session patch

[Marcus Börger]

Tell me if i'm wrong
From the webpage german freely translated
to english
> Hervorragende Eignung für hoch frequentierte Websites 
=>Especially for highly frquented webpages.
I do not think having your cookie beeing part of dns is a fast solution

or did you your self register many of these entrie before you
brought
your page up because than i get me a dns server download your 
possible cookielist (then it is a download :-) ) and and do a little
easy
hacking. You cannot do anything against the that download ...
If you generate them dynamically your pages are slower than can be
and you cannot work against that with more machines.
> Tracking unabhängig von Cookies, IP-Adressen und
URL-Kodierung 
=>User tracking without using cookies, ip-adresses or
url-rewriting
but i typed
www.sevenval.de
and i got xe7f5b0b802ffd79dd702985633bdb675.sevenval.de
that is one x plus a 32 hex so you use md5?
And of cause you do not use IP adresses if so you could not distinguish
between usesers sitting behind a firewall in an intranet.
Cookie - yes you need not with that solution.
> Domainübergreifendes Tracking
=usertracking over multiple domains 
That's whay you need an application server -> for me it seems you only
need sessions spread over mulitple machines behind a firewall. So your
problem is that you are not able to redirect the user request to the server
which holds the session for the user.
Solution for smaller sites with only a few web servers:
Install one web server direct behind the firewall. 
This works as load balancer using something like 
1) www.x.y/? ---(db)---> z.dmz? + 
2) www.x.y?& ---(db)---> z.dmz? + 
So each server in the dmz handles only his own session requests.
When no session is used direct to on free webserver.
When a new session is generated store session-id+local-ip in db.
The result is that i am using a db instead a dns-server. Questions
a) what is faster?
b) what is recognized by the user?
answer
a) I don't know what is faster internally but my db solution needs less 
machine power (Additionally i suppose you have a db also...) and the 
db solution is faster externally because it does not produce unnecessary 
dns traffic.
b) With the db solution the user does not see that he is directed to another 
host.
and hey i did not even change seesion-id generation!
marcus
At 02:29 29.03.2002, Stefan Esser wrote in answer to Egon Schmid:
Hi,
> Have a look at www.sevenval.com. Sorry everything is German. If you
Hmm yeah but if your browser is really not able to do proper content
negotiation, there is still an "english" button in the right lower edge of
the page...
> regocnize what I mean. The generated URLs are patents.
> Please ask Hartmut for more details.
Ask more about what? That this stuff is patented is funny, because it shows
how idiotic the european law is, but thats another story. Anyway I wonder
what Hartmut can tell me about Sevenval that I don't already know :)
Stefan

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

Re: [PHP-DEV] Re: Re: Session patch

[Egon Schmid]

From: "Stefan Esser" <[EMAIL PROTECTED]>

> > Have a look at www.sevenval.com. Sorry everything is German. If
you
>
> Hmm yeah but if your browser is really not able to do proper
content
> negotiation, there is still an "english" button in the right lower
edge of
> the page...

Yeah, I have found it now, if I make the window sooo large that I
cannot see my TV.

> > regocnize what I mean. The generated URLs are patents.
> > Please ask Hartmut for more details.
>
> Ask more about what? That this stuff is patented is funny, because
it shows
> how idiotic the european law is, but thats another story. Anyway I
wonder
> what Hartmut can tell me about Sevenval that I don't already know
:)

Sevenval HIT based on the patented Host Identification Tracking
technology, is a new method of enabling even suppliers advertising
on heavily visited websites to analyze the efficacy of their web
presentation and improve it using a range of statistical tools.

Sevenval was a sponsor for the PHP Kongress in 2000
(http://www.php-kongress.de/2000/). The company logo appeared only
on the page at Hartmut´s summary.

-Egon


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

Re: [PHP-DEV] Re: Re: Session patch

[Stig S. Bakken]

What has that got to do with anything?

 - Stig

On Thu, 2002-03-28 at 20:11, Egon Schmid wrote:
> No, I don´t read such nonsense patents.
> 
> -Egon
> 
> - Original Message -
> From: "Stefan Esser" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, March 28, 2002 7:35 PM
> Subject: Re: [PHP-DEV] Re: Re: Session patch
> 
> 
> > Hi,
> >
> > I have not followed the discussion, but its nonsense to force
> people to use
> > PHP generated session IDs. Its an argument against using PHP.
> > There are several situations where it is not possible to let PHP
> generate
> > the session ids. Especially if you use stuff like the Sevenval FIT
> or HIT
> > technology which makes use of hostnames to contain the session
> ids.
> > Stuff like this is needed to track f.e. shockwave or flash
> content.
> >
> > Stefan
> >
> > --
> > 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] Re: Re: Session patch

[Egon Schmid]

With European patents in general and with the sevenval patents. I
have visited the website today and it seems that the references to
that patents are now removed from there website.

If you know the conference paper from the last PHP Kongress in
Cologne, you can see the company logo at the page of Hartmut´s
abstract :) He really dislike such a advertising himself.

-Egon

- Original Message -
From: "Stig S. Bakken" <[EMAIL PROTECTED]>
To: "Egon Schmid" <[EMAIL PROTECTED]>
Cc: "Stefan Esser" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, March 30, 2002 12:21 PM
Subject: Re: [PHP-DEV] Re: Re: Session patch


What has that got to do with anything?

 - Stig

On Thu, 2002-03-28 at 20:11, Egon Schmid wrote:
> No, I don´t read such nonsense patents.
>
> -Egon
>
> - Original Message -
> From: "Stefan Esser" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, March 28, 2002 7:35 PM
> Subject: Re: [PHP-DEV] Re: Re: Session patch
>
>
> > Hi,
> >
> > I have not followed the discussion, but its nonsense to force
> people to use
> > PHP generated session IDs. Its an argument against using PHP.
> > There are several situations where it is not possible to let PHP
> generate
> > the session ids. Especially if you use stuff like the Sevenval
FIT
> or HIT
> > technology which makes use of hostnames to contain the session
> ids.
> > Stuff like this is needed to track f.e. shockwave or flash
> content.
> >
> > Stefan
> >
> > --
> > 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] Re: Re: Session patch

[Stefan Esser]

Sorry, what do you want to tell us? Your mail doesn't make any sense.

Stefan


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

Re: [PHP-DEV] Re: Re: Session patch

[Egon Schmid]

From: "Stefan Esser" <[EMAIL PROTECTED]>

> Sorry, what do you want to tell us? Your mail doesn't make any
sense.

Please tell us more about the patents from the German company
www.sevenval.de.

-Egon


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

Re: [PHP-DEV] Re: Re: Session patch

[derick]

On Sat, 30 Mar 2002, Egon Schmid wrote:

> From: "Stefan Esser" <[EMAIL PROTECTED]>
> 
> > Sorry, what do you want to tell us? Your mail doesn't make any
> sense.
> 
> Please tell us more about the patents from the German company
> www.sevenval.de.

Sure, but what do patents have to do with Marks' patch for sessions?

Derick

---
  PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] Re: Re: Session patch

[Egon Schmid]

From: <[EMAIL PROTECTED]>
> On Sat, 30 Mar 2002, Egon Schmid wrote:
>
> > From: "Stefan Esser" <[EMAIL PROTECTED]>
> >
> > > Sorry, what do you want to tell us? Your mail doesn't make any
> > sense.
> >
> > Please tell us more about the patents from the German company
> > www.sevenval.de.
>
> Sure, but what do patents have to do with Marks' patch for
sessions?

Sure it doesn´t have anything with session. It is the host in the
URL which is patented. Please poke around at www.sevenval.de and you
can see what I mean.

There is a chapter in the German FAQ, sorry only in German, and that
you find a translator to read it in your favorite language:

 -Egon





17.7 Was ist das Sevenval-Patent?
Referenzen: 17.7 Was ist das Sevenval-Patent?
http://www.koehntopp.de/php/faq-phplib.html#phplib-7
17.7 Was ist das Sevenval-Patent?
http://develnet.org/tech/dclp/phplib.html#phplib-7

Antwort von Kristian Köhntopp:


Die Firma Sevenval hat sich die Speicherung der Session-ID im
Hostnamen patentieren lassen. Das Patent von Walkowiak, Olaf und
Sponagl, Paul umfaßt laut Abstract folgendes:

In a method for providing state information in a stateless data
communications protocol, the state information being provided
between a client and a server site, said server site being
accessible at each of cluster of site names, one site name of a said
cluster of site names is used for accessing said server site, said
site name containing the encoded state information. A computer
program product and an apparatus compromise corresponding features.
The invention creates a way of providing state information in a
stateless data communication protocol with very little effort.

In der Patentschrift:

... merits of the inventors have shown that the configuration of
both the nameserver and the server site in the way described are
possible with very little programming effort.

Im Wesentlichen versucht die Schrift, auf ca. 30 Seiten mit vielen
unnötigen Worten anhand von Apache, Bind, PHP, mod_rewrite und
mod_unique zu erklären, wie die Technik funktioniert - genauso, wie
es jeder nach wenigen Minuten selber nachkonfiguriert hat. Klar ist,
daß zwar die Idee, nicht aber die Konfiguration geschützt ist.

Die Erfindung umfaßt, unter Benutzung obiger "said" Methode
insbesondere:

Die Anwendung mit HTTP

Die Benutzung von Redirects

Die Verwendung mit IP-Nummern anstelle von Domain-Namen.

Im anschließenden Gespräch ergaben sich noch folgende Infos:

Die Benutzung soll nur für den kommerziellen Gebrauch
kostenpflichtig sein. Unis etc. sollen es so machen können.

Kosten sind angedacht in der Größenordnung von ca. 30.000 DM pro
Server pro Jahr.

Es besteht Einigkeit darüber, daß das genannte Verfahren primär dem
Designer nützt.








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

Re: [PHP-DEV] Re: Re: Session patch

[Hartmut Holzgraefe]

Egon Schmid wrote:
> If you know the conference paper from the last PHP Kongress in
> Cologne, you can see the company logo at the page of Hartmut´s
> abstract :) He really dislike such a advertising himself.

Please stop citing me out of context.

No, i didn't dislike the advertisement.
Yes, i did dislike the patent issue itself.
Yes, i did dislike the placement of the add in the conference
material which seemed to imply that especially my talk and my
person were sponsored by 7val, although they were sponsoring
the event in general and their logo just ended up on 'my'
page by pure chance. What i really disliked was not even the
placement of the advertisement itself but the fact that a lot
of people asked me about my relation to 7val all day...



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

Re: [PHP-DEV] Re: Re: Session patch

[Kristian Köhntopp]

Marcus Börger wrote:
> I do not think having your cookie beeing part of dns is 
> a fast solution or did you your self register many of 
> these entrie before you brought
> your page up because than i get me a dns server download your
> possible cookielist (then it is a download :-) ) and and do a
> little easy
> hacking.

i think you are missing here the possibility of wildcard A
records such as

*   IN  A   86400   w.x.y.z

Such a record in your zone will match each and any host. See
http://gugelhupfdiwupf.lernnetz.de for an application that
utilizes this. Wildcard-A's are especially useful in conjunction
with mod_vhost, if your are not using them for session ids.

Also, there is no such list to download. There is just the
above line in your zone.

> And of cause you do not use IP adresses if so you could not
> distinguish
> between usesers sitting behind a firewall in an intranet.
> Cookie - yes you need not with that solution.

If I am informed correctly, one of the claim in the SevenVal 
Patent essentially covers Wildcard-A's. Technically, this
cannot be granted, as Google easily finds prior application
of Wildcard-A's that dates back to the late 80ies. Yet, it is
still an unchallenged claim and therefore a reaily before the
law. The essential "new" idea that SevenVal wants to protect
is the combination of two standard ideas of Wildcard-A's and
secure md5 session ids, thus the patent - reality of patent
law today.

Kristian

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