phplib-users

Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

[Giancarlo <gia...@na...>]

Then you agree on the other points of the message?

Giancarlo


 Kristian Koehntopp <kr...@ko...> a écrit le  8/7/02 20:41:

>Am Do 4.Juli 2002 23:38 
>schrieb Giancarlo:
>> I would like to know which 
>other major scripting 
>language allows any
>> session propagation other 
>than cookie. 
>
>http://www.google.com/sear
>ch?q=cookie%20munger
>
>http://www.six.udc.es/softw
>are/technet/17.html
>"Using the IIS Resource Kit 
>CD"
>
>"Cookie Munger
>
>Cookie Munger is a filter 
>that enables Active Server 
>Pages to provide 
>cookielike functionality to 
>browsers that do not 
>support cookies or that do 
>not accept them."
>
>
>-- 
>http://www.amazon.de/exec
>/obidos/wishlist/18E5SVQ5H
>JZXG
>
>
>
>-----------------------------
>--------------------------
>This sf.net email is 
>sponsored by:ThinkGeek
>Oh, it's good to be a geek.
>http://thinkgeek.com/sf
>_____________________________
>__________________
>Phplib-users mailing list
>Php...@li...urcefor
>ge.net
>https://lists.sourceforge.net
>/lists/listinfo/phplib-users

Re: Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

[Maxim D. <max...@bo...>]

Hello, Giancarlo,

> I would like to know which other major scripting language allows any
> session propagation other than cookie. 

Any language. It is not question of language. It is a question of
technology. Session module is not a core part of PHP. It is just an
extension, just like in ASP, JSP/Servlets and other. Any good
session handling object is written with cookie-less environment in
mind. Cookies OR url rewriting are the only available methods in HTTP
for the session propagation, and both are used.
Look at Amazon.com. What do you think those long meaningless digit
strings in urls do? They are nothing more than session identifiers.
Well, they at Amazon do extra work - they even don't remove SIDs when
cookies are enabled.
Then look at Sun.com. They use the same technology, just dig beyond
the first advertising pages to Sun's shop or something else that
requires a session to work - you'll see the SID in urls.
Of course, they use servlets/JSP.
Look at WROX site, they also munge cookies and run ASP.
Zope (the system in Python) also use both cookies and url rewriting
for session handling.




-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

[Guillaume D. <gde...@pr...>]

> extension, just like in ASP, JSP/Servlets and other. Any good
> session handling object is written with cookie-less environment in
> mind. Cookies OR url rewriting are the only available methods in HTTP
> for the session propagation,

Well... in a formular, you use an hidden input to propagate the SID...
it's not strictly the same thing of an URL rewriting (if you use the
method POST, I mean...). URL use the HTTP GET method...

It's more clearly to write : <form action="toto.php"
method="post"><input type="hidden" name="SID"
value="fdsfsdfdsfdfsfdsfsdf"> than to write <form
action="toto.php?SID=dsfdsfsdfdsfdssf" method="post"> ... doing this
works... but it's not a good way to program IMHO... mixing GET and POST
variables in the same request... hurk... ;-)

Re[2]: Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

[Maxim D. <max...@bo...>]

Hello Guillaume,

Tuesday, July 09, 2002, 1:24:37 PM, you wrote:
GD> Well... in a formular, you use an hidden input to propagate the SID...
GD> it's not strictly the same thing of an URL rewriting (if you use the
GD> method POST, I mean...). URL use the HTTP GET method...

Ok, but what to do with hiddens in GET forms? SID is appended to the
URL anyway, from the action attribute or from a hidden field.
Amazon even do not use GET parameters - it injects the SID into
url in the way http://www.amazon.com/...path.../...SID../...etc... end
extracts SID from path.
There are a lot of ways to save SID in URL - one could use DNS tricks
(e.g. http://sessionID.www.server.com), PATH_INFO (like Amazon does), GET
parameters. All the tricks imply URL rewriting.
Of course, there's not a big deal to implement a POST fallback
method (I did) - you should rewrite all links to POST forms at the
server, or use client-side onClick event to generate POST forms from
links on the fly and really POST them instead of just following the
links. But I suppose It would be users' nightmare - the Back/Forward
buttons would become useless. Of course, SID should be included

GD> It's more clearly to write : <form action="toto.php"
method="post">><input type="hidden" name="SID"
GD> value="fdsfsdfdsfdfsfdsfsdf"> than to write <form
GD> action="toto.php?SID=dsfdsfsdfdsfdssf" method="post"> ... doing this
GD> works... but it's not a good way to program IMHO... mixing GET and POST
GD> variables in the same request... hurk... ;-)

No one does. Embedding hidden field with SID into any form (POST or
GET) is sufficient. Only local relative links (<a href=/some/page) and
redirects are usually being rewrote.


-- 
Best regards,
Maxim Derkachev mailto:max...@bo...
IT manager,
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
www.books.ru, www.symbol.ru 

Re: Re[2]: Rp.: Re: Rp.: Re: [Phplib-users] Doc suggestions

[Guillaume D. <gde...@pr...>]

> Ok, but what to do with hiddens in GET forms? SID is appended to the
> URL anyway, from the action attribute or from a hidden field.
> Amazon even do not use GET parameters - it injects the SID into
> url in the way http://www.amazon.com/...path.../...SID../...etc... end
> extracts SID from path.
> There are a lot of ways to save SID in URL - one could use DNS tricks
> (e.g. http://sessionID.www.server.com), PATH_INFO (like Amazon does),
GET
> parameters. All the tricks imply URL rewriting.
> Of course, there's not a big deal to implement a POST fallback
> method (I did) - you should rewrite all links to POST forms at the
> server, or use client-side onClick event to generate POST forms from
> links on the fly and really POST them instead of just following the
> links. But I suppose It would be users' nightmare - the Back/Forward
> buttons would become useless. Of course, SID should be included

I'm totally agree with you. I just wanted to precise this particular
point

> GD> It's more clearly to write : <form action="toto.php"
> method="post">><input type="hidden" name="SID"
> GD> value="fdsfsdfdsfdfsfdsfsdf"> than to write <form
> GD> action="toto.php?SID=dsfdsfsdfdsfdssf" method="post"> ... doing
this
> GD> works... but it's not a good way to program IMHO... mixing GET and
POST
> GD> variables in the same request... hurk... ;-)
>
> No one does.

Unfortunately there are "morons" to do that... I've seen this kind of
ugly code many times in web application (especially in caddy routine...)

> Embedding hidden field with SID into any form (POST or
> GET) is sufficient. Only local relative links (<a href=/some/page) and
> redirects are usually being rewrote.

I'm agree also....