[PHP-INSTALL] why is the session recreated?
Title: why is the session recreated?
Hello!
I have a problem with sessions. It is working as it should in an installation using PHP 4.2.3 but I cannot get it to work using PHP 4.3.3!
The rest of the enviornment is Solaris 7 and iPlanet WS 4.1
The setup is like this: An HTML page where the user submits user and password, next a PHP script which is called using the POST method which validates the user, and then the first PHP script of the application which is accessed using the GET method.
When I am tracing the web server I can see the the following is posted to the first PHP script:
POST /validate.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, application/x-shockwave-flash, */*
Referer: http://1.2.3.4/refering.html
Accept-Language: en-us
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Host: 1.2.3.4
Content-Length: 30
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: NSES40Session=0%253A401f9667%253A4ebb2335a6106cf3; YKKOSKANAVA=72dec6197fca54fce2776688ea1bd926
login=demo&password=demo
The first rows of validate.php are:
session_start();
Then I can see the process read from /dev/random and a creation of a session file:
15257: 4217096.5446 0.0003 open("/dev/random", O_RDONLY) = 20
15257: 4217096.5449 0.0003 read(20, 0xF71BE508, 16) = 16
15257: 16 uD0F7 3 2 @ NE7 r =19D083B7
15257: 4217096.5452 0.0003 close(20) = 0
15257: 4217096.5515 0.0063 resolvepath("/export/home/php/session//sess_0778039f10e73ce1523380ef721b7ad3", 0xF71BE490, 1024) Err#2 ENOENT
15257: 4217096.6229 0.0714 open("/export/home/php/session/sess_0778039f10e73ce1523380ef721b7ad3", O_RDWR|O_CREAT, 0600) = 20
As you can see there is a new session file created, even though the browser sent us a cookie!
This is the redirection sent back to the web browser:
HTTP/1.1 302 Moved Temporarily
Server: Netscape-Enterprise/4.1
Date: Tue, 03 Feb 2004 12:39:15 GMT
Set-Cookie: YKKOSKANAVA=0778039f10e73ce1523380ef721b7ad3;expires=Tue, 03-Feb-04 15:59:15GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location:application.php
Content-type: text/html
Connection: close
And here is the GET request for application.php:
GET /application.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword,application/vnd.ms-powerpoint, application/x-shockwave-flash, */*
Referer: http://1.2.3.4/refering.html
Accept-Language: en-us
Accept-Encoding:gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Host: 1.2.3.4
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: NSES40Session=0%253A401f9667%253A4ebb2335a6106cf3; YKKOSKANAVA=0778039f10e73ce1523380ef721b7ad3
And once again, the session_start in the beginning of the PHP script is reading from /dev/random, and creating a new session file, which is reflected in the cookie reply to the web browser, and of course the application has detected the session has ended...
HTTP/1.1 302 Moved Temporarily
Server: Netscape-Enterprise/4.1
Date: Tue, 03 Feb 2004 12:39:16 GMT
Set-Cookie: YKKOSKANAVA=cf6c44eb0e4a9b83ed5b9c963bd796a0;expires=Tue, 03-Feb-04 15:59:16GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location:end_of_session.php
Content-type: text/html
Connection: close
I almost forgot to mention - session.auto_start is set to 0 in php.ini.
For some reason the session_start function is unable to recognize the cookie obviously sent to the web browser. What could be wrong in the setup?
/jonas
Jonas Blåberg
Mandator Infrastructure
Kruthusgatan 17,6
S-411 04 Göteborg
[EMAIL PROTECTED]
office: +46-(0)31-739 84 54
mobile: +46-(0)709-95 00 68
[PHP-INSTALL] Ä«µåÀܾ×À» Çö±ÝÀ¸·Î,,(Àü±¹ÃÖÃÊ8%)
Title: Untitled Document 카드잔여한도!!전화로 즉시할인!! (전국최저%!! 국민,삼성8%) 서울기획 박지원부장(0505-616-6161) ※ 대출절자 카드잔여한도 확인 → 전화로 대출신청 → 본인확인 → 본인통장입금 ※ 업무시간(대출가능시간) 월~토요일:오전 9:30분부터 오후 6:00시 까지이며 토요일도 오전9:30에서 오후6:00까지 정상영업합니다. ⊙ 전국에 신용카드를 소지하신 고객님,, 일시불,할부(3~18개월) 현재 사용가능한 카드잔여한도(50~3000만원)를 현금화하여 30분안에 고객님의 본인 통장으로 입금하여 드립니다. ex) 100만원 카드대출신청 => 89만원 본인통장입금 500만원 카드대출신청 => 445만원 본인통장입금 1000만원 카드대출신청 => 890만원 본인통장입금 (단, 국민과 삼성카드는 8%에 할인해 드립니다.) ※ 저희 업체는,,, ▶국민과 삼성카드는 8%에 할인해 드립니다◀ ⊙방문하실 필요없습니다.전국어디서나!! 전화로!! 30분내 대출가능합니다. ⊙저희 업체는 실제로 물품을 구입하기 때문에 전혀 걱정하실 필요없읍니다. 서울기획 박지원부장(무료전화: 0505-616-6161)전국 어디서나!! 전화 한통으로 O.K!! (☎대출신청: 무료: 0505-616-6161) 서울기획 박지원부장 0505-616-6161 바로 대출 신청하세요.
SV: [PHP-INSTALL] why is the session recreated?
Title: why is the session recreated?
Hello!
Important additional information: session.name is
set to YKKOSKANAVA in php.ini file, which should explain the strange name of the
cookie.
/jonas
-Ursprungligt meddelande-Från: Jonas Blåberg
[mailto:[EMAIL PROTECTED]Skickat: den 4 februari 2004
11:44Till: [EMAIL PROTECTED]Ämne: [PHP-INSTALL]
why is the session recreated?
Hello!
I have a problem with sessions. It is working as it
should in an installation using PHP 4.2.3 but I cannot get it to work using
PHP 4.3.3!
The rest of the enviornment is Solaris 7 and
iPlanet WS 4.1
The setup is like this: An HTML page where the user
submits user and password, next a PHP script which is called using the POST
method which validates the user, and then the first PHP script of the
application which is accessed using the GET method.
When I am tracing the web server I can see the the
following is posted to the first PHP script:
POST /validate.php HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint,
application/x-shockwave-flash, */*
Referer: http://1.2.3.4/refering.html
Accept-Language: en-us Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Host: 1.2.3.4 Content-Length: 30 Connection:
Keep-Alive Cache-Control: no-cache
Cookie:
NSES40Session=0%253A401f9667%253A4ebb2335a6106cf3;
YKKOSKANAVA=72dec6197fca54fce2776688ea1bd926
login=demo&password=demo
The first rows of validate.php are:
session_start();
Then I can see the process read from /dev/random
and a creation of a session file:
15257: 4217096.5446
0.0003 open("/dev/random",
O_RDONLY)
= 20 15257:
4217096.5449 0.0003 read(20, 0xF71BE508,
16)
= 16 15257: 16 uD0F7 3 2
@ NE7 r =19D083B7 15257:
4217096.5452 0.0003
close(20)
= 0 15257:
4217096.5515 0.0063
resolvepath("/export/home/php/session//sess_0778039f10e73ce1523380ef721b7ad3",
0xF71BE490, 1024) Err#2 ENOENT
15257: 4217096.6229
0.0714 open("/export/home/php/session/sess_0778039f10e73ce1523380ef721b7ad3",
O_RDWR|O_CREAT, 0600) = 20
As you can see there is a new session file created,
even though the browser sent us a cookie!
This is the redirection sent back to the web
browser:
HTTP/1.1 302 Moved Temporarily Server: Netscape-Enterprise/4.1 Date: Tue, 03 Feb 2004 12:39:15 GMT Set-Cookie: YKKOSKANAVA=0778039f10e73ce1523380ef721b7ad3;expires=Tue,
03-Feb-04 15:59:15GMT; path=/ Expires: Thu,
19 Nov 1981 08:52:00 GMT Cache-Control:
no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache Location:application.php Content-type: text/html Connection:
close
And here is the GET request for
application.php:
GET /application.php HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-excel, application/msword,application/vnd.ms-powerpoint,
application/x-shockwave-flash, */*
Referer: http://1.2.3.4/refering.html
Accept-Language: en-us Accept-Encoding:gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Host: 1.2.3.4 Connection: Keep-Alive Cache-Control: no-cache Cookie:
NSES40Session=0%253A401f9667%253A4ebb2335a6106cf3;
YKKOSKANAVA=0778039f10e73ce1523380ef721b7ad3
And once again, the session_start in the beginning
of the PHP script is reading from /dev/random, and creating a new session
file, which is reflected in the cookie reply to the web browser, and of course
the application has detected the session has ended...
HTTP/1.1 302 Moved Temporarily Server: Netscape-Enterprise/4.1 Date: Tue, 03 Feb 2004 12:39:16 GMT Set-Cookie: YKKOSKANAVA=cf6c44eb0e4a9b83ed5b9c963bd796a0;expires=Tue,
03-Feb-04 15:59:16GMT; path=/ Expires: Thu,
19 Nov 1981 08:52:00 GMT Cache-Control:
no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache Location:end_of_session.php Content-type: text/html Connection:
close
I almost forgot to mention - session.auto_start is
set to 0 in php.ini.
For some reason the session_start function is
unable to recognize the cookie obviously sent to the web browser. What could
be wrong in the setup?
/jonas
Jonas Blåberg Mandator Infrastructure Kruthusgatan 17,6
S-411 04 Göteborg [EMAIL PROTECTED] office:
+46-(0)31-739 84 54 mobile: +46-(0)709-95
00 68
[PHP-INSTALL] ÃֽŠī¸Þ¶ó ÇÚµåÆùÀ¸·Î ±³È¯Çϼ¼¿ä.011,016,017,018,019 °í°´´Ô
[PHP-INSTALL] Hi
Dear Sir/Madam, I have install PHP, Apache, and MySql to my PC, and I followed all the instruction in "install.txt" in PHP folder, I have open Apache and MySql services before I try to run it, and when I try to run one of PHP command "db_connect" and I am unable to connect database please help thank you _ Get 10mb of inbox space with MSN Hotmail Extra Storage http://join.msn.com/?pgmarket=en-sg
[PHP-INSTALL] Re: Error
This is an automated email reply to acknowledge your message to [EMAIL PROTECTED] Slurp is Inktomi Corporation's web-indexing robot. It collects documents from the World Wide Web to build a searchable index for search services using the Inktomi search engine. For more information or to see a list of partners with whom we work, please see: http://www.inktomi.com/products/web_search/partners.html For some frequently asked questions on Slurp and Inktomi's web crawling and search technology, please see later in this email. Some web site administrators do not want robots to index their site, or certain areas of their site. This is particularly true for sections that contain dynamically generated pages, CGI scripts, and so on. There is a de facto standard called the "Robots Exclusion Standard" (RES) which allows web administrators to tell robots which areas of the site they are allowed to visit, and which are off limits. RES involves putting a file called "robots.txt" in the document root of the web site, this file is parsed by a robot to determine what site restrictions exist. Every robot that visits your site should request the robots.txt file from your web server. If there is no robots.txt file, the RES specifies that the robot can visit all parts of the site if it wishes. Slurp obeys robots.txt restrictions. Every time Slurp, visits your site it will request the robots.txt file. If your site doesn't have a robots.txt, Slurp will obey its own rules on which URL's to visit (for example, Slurp doesn't visit the standard places to store CGI scripts even if robots.txt allows it to). If you don't have a problem with Slurp's visits, or other robots visits, then you don't need a robots.txt file. If you just want to stop getting "robots.txt not found" errors in your server logs, you can simply create an empty robots.txt file. For more background on Slurp, please see: http://www.inktomi.com/slurp.html For more information on the RES, please see: http://www.robotstxt.org/wc/exclusion.html A number of frequently asked questions regarding Slurp and Inktomi's search system are available at: http://support.inktomi.com/Search_Engine/Product_Info/FAQ/searchfaq.html If your question is not answered by the links above, or if you still need further assistance, please send an email with a full problem description to [EMAIL PROTECTED] Thank you for your interest in Slurp! Inktomi Corporation ---
[PHP-INSTALL] Re: Status
This is an automated email reply to acknowledge your message to [EMAIL PROTECTED] Slurp is Inktomi Corporation's web-indexing robot. It collects documents from the World Wide Web to build a searchable index for search services using the Inktomi search engine. For more information or to see a list of partners with whom we work, please see: http://www.inktomi.com/products/web_search/partners.html For some frequently asked questions on Slurp and Inktomi's web crawling and search technology, please see later in this email. Some web site administrators do not want robots to index their site, or certain areas of their site. This is particularly true for sections that contain dynamically generated pages, CGI scripts, and so on. There is a de facto standard called the "Robots Exclusion Standard" (RES) which allows web administrators to tell robots which areas of the site they are allowed to visit, and which are off limits. RES involves putting a file called "robots.txt" in the document root of the web site, this file is parsed by a robot to determine what site restrictions exist. Every robot that visits your site should request the robots.txt file from your web server. If there is no robots.txt file, the RES specifies that the robot can visit all parts of the site if it wishes. Slurp obeys robots.txt restrictions. Every time Slurp, visits your site it will request the robots.txt file. If your site doesn't have a robots.txt, Slurp will obey its own rules on which URL's to visit (for example, Slurp doesn't visit the standard places to store CGI scripts even if robots.txt allows it to). If you don't have a problem with Slurp's visits, or other robots visits, then you don't need a robots.txt file. If you just want to stop getting "robots.txt not found" errors in your server logs, you can simply create an empty robots.txt file. For more background on Slurp, please see: http://www.inktomi.com/slurp.html For more information on the RES, please see: http://www.robotstxt.org/wc/exclusion.html A number of frequently asked questions regarding Slurp and Inktomi's search system are available at: http://support.inktomi.com/Search_Engine/Product_Info/FAQ/searchfaq.html If your question is not answered by the links above, or if you still need further assistance, please send an email with a full problem description to [EMAIL PROTECTED] Thank you for your interest in Slurp! Inktomi Corporation ---
