PHP: session_start

Opis

bool session_start ( void )

session_start() tworzy sesję lub wznawia bieżącą na podstawie aktualnego identyfikatora sesji przekazanego przy wywołaniu, poprzez metodę GET, POST lub ciasteczko.

Jeśli chcesz, aby sesja była nazwana, przed wywołaniem session_start() musisz wywołać session_name().

Ta funkcja zawsze zwraca wartość TRUE.

Notatka: Jeśli używasz sesji opartych o ciasteczka, to session_start() musi być wywołane przed wysłaniem jakichkolwiek danych do przeglądarki.

Przykład 1. Przykład sesji: page1.php


<?php

// page1.php



session_start();



echo 'Witaj na stronie #1';



$_SESSION['kolor']     = 'zielony';

$_SESSION['zwierze']   = 'kot';

$_SESSION['czas']      = time();



// Działa jeśli ciasteczko sesyjne zostało zaakceptowane

echo '<br /><a href="page2.php">strona 2</a>';



// Lub może przekaż ciasteczko sesyjne, jeśli to konieczne

echo '<br /><a href="page2.php?' . SID . '">strona 2</a>';

?>

Po odwiedzeniu strony page1.php, druga strona, page2.php będzie magicznie zawierała dane sesji. W rozdziale Sesje znajduje się więcej informacji na temat propagowania identyfikatora sesji, gdzie można znaleźć na przykład wytłumaczenie co zawiera stała SID.

Przykład 2. Przykład sesji: page2.php


<?php

// page2.php



session_start();



echo 'Witaj na stronie #2<br />';



echo $_SESSION['kolor']; // zielony

echo $_SESSION['zwierze'];   // not

echo date('Y m d H:i:s', $_SESSION['time']);



// Tu można wstawić SID, podobnie jak to był na page1.php

echo '<br /><a href="page1.php">page 1</a>';

?>

W celu stworzenia nazwanej sesji, niezbędne jest wywołanie funkcji session_name() przed wywołaniem session_start().

session_start() zarejestruje wewnętrzny uchwyt obsługi wyjścia dla przepisywania URLi jeśli włączona jest opcja trans-sid. Jeśli użytkownik używa ob_gzhandler lub podobne z ob_start(), kolejność uchwytów obsługi wyjścia jest ważna dla prawidłowego wyjścia. Na przykład, użytkownik musi zarejestrować ob_gzhandler przed rozpoczęciem sesji.

Notatka: Wskazane jest użycie zlib.output_compression zamiast ob_gzhandler

Notatka: Od PHP 4.3.3, wywołanie session_start() podczas gdy sesja już została rozpoczęta, spowoduje błąd poziomu E_NOTICE. Drugie rozpoczęcie sesji zostanie zignorowane.

Patrz także: $_SESSION, session.auto_start i session_id().

User Contributed Notes


in responce to gadgetguy03 at lycos dot com

SESSION LOST ON HEADER REDIRECT (CGI on IIS 5.0)

and ma at technoprint dot ch

I have the same server setup.

I fought this for days. Then I realized that If I create the session with session_start() without setting any session variables on the page before I needed to set session variables and then do a redirect, everything magically worked.

It was only when there was no session in existence that the following code would not work as expected.

/***** sess1.php *****/

session_start();

$_SESSION["key1"] = "testvalue";

session_write_close()

header("Location: sess2.php");



I've seen several post regarding this same issue, so I hope this is helpful.


foltscane at yahoo dot com wrote about people losing session information on page redirects. 



The problem is some times the redirect may kick you off to the next page before all the session variables have been saved. The true solution to lost session vars on redirect is to simply call session_write_close(); before setting the redirect header. This will insure that php finishes writing the session info before page redirect gets underway.



ie:

<?

    session_start();

    $_SESSION['forward'] = "This session data will not be lost!";



    session_write_close();

    header('Location: nextpage.php');

?>


Because session_start() does indeed prevent another page using session_start() from running until the first one is done, i use session_write_close() before doing any operation that takes significant time. For instance, session_write_close() worked as a lifesaver for me when automatically uploading files to a user (forcing a download instead of a link). When files are large, my site was not able to upload more than one file at a time to a user. By using session_write_close() before beginning the file upload, my users can now download as many big files as they like, at the same time. Example:



<?

session_start();

/* Do session stuff here; security; logging; etc. */

session_write_close();

/* NOW write out the requested file. */

header("Content-type: audio/x-mpeg"); /* or whatever type */

header("Content-Disposition: attachment; filename=" . $filename); 

header("Content-Length: " . $filesize);

header("Content-Transfer-Encoding: binary\n\n");

header("Pragma: no-cache"); 

header("Expires: 0"); 

$file_contents = file_get_contents($filepath);    

print($file_contents);

?>


a quick note on sessions and ie6 losing them. this one took me months to work out..



in forefox everything worked fine between pages (in redirects and include statements) then in ie5 and 6 the session would be lost on only _one_ of my pages for no apparent reason.



long story short, it turned out that this particular failing page had references to broken images with alt text of "no image". every time ie requested the image and couldnt find it it displayed the icon of a broken image and killed the session as well! firefox behaved nicely and displayed "no image"



an if statement later to display text instead of a broken image and everything worked. hope this saves someone the headache it gave me..



servers affected: apache2/php4/win32, apache1/php4/linux and most likely more


I struggled with this for 3 days and wanted to share my thoughts, if anything is wrong, someone please correct me.



When you do a session_start() and it isn't a persistant session (meaning when the browser is closed the session is ended) it does not write a cookie to your computer and it does not re-write the url if you have cookies turned off. Instead it simply passes it along in the http header inforamation as Cookie: PHPSESSID=79b928a4cc86d5761d074e40f5f9b7f7 and references the file on the server that corresponds to store variables



Then next step is under IE 6.0 all child windows share the http information with the parent. Meaning if you have a window open and you have a link that opens a new window, they share that info.



My problem was I have two subdomains with seperate securities. I wanted to pass a user from one to the other using seperate securities and sessions. The only way to do this is to name the sessions using session_name('whatever'); on at least one of the sites or else the cookies will over write each other. Once I did this the http header info looked like this Cookie: intranet=cd429d1947ffc947856065f0bfdee799; PHPSESSID=79b928a4cc86d5761d074e40f5f9b7f7 

and everything worked fine


As a side note, if You use in your script



<?



session_start();

$_SESSION["foo"] = 'bar';

session_write_close()



require("some_script.php");



?>



//some_script.php



<?



session_start();

$tmp = $_SESSION["foo"];

session_write_close();



print("$tmp");



?>



In required script session values aren't visible.

Only way is to redirect browser to some_script.php

and then sessions start to work.



This happens at Windows platform. If someone could input

results from Unix/Linux platform, it would be nice then.



Still have no idea how to put working sessions in required 

script, hope someone will save time from avoiding this.


Here is a crazy feature -- you get one concurrent database connection per session, transparent to the programmer!



I am running php 5.0.4 on iis 6 (yeah, I know...). I noticed under stress testing that database connections were my bottleneck. I spent like 5 hours turning this on, that off, etc because I could not get php to create more than one database connection at a time, regardless of how many requests it was servicing. I tried running php as fastcgi, cgi, and isapi module. I tried using mysql and mysqli extensions. Same thing every time. Then I happened to turn off auto-start sessions and commented out my session_start() calls, and all of the sudden I get multiple connections like I expected!



Don't let this happen to you -- don't freak out! Apparently something somewhere tries to make sure your visitors don't get more than their share of your resources, so they get one db connection per session. I can't say it is what I would like to happen, but now that I know, it doesn't bother me much :) Hope this saves someone some time and headache!


If you open a popup window (please no commercial ones!) with javascript window.open it might happen IE blocks the session cookie.

A simple fix for that is opening the new window with the session ID in a GET value. Note I don't use SID for this, because it will not allways be available.



----page.php----

//you must have a session active here

window.open('popup.php?sid=<?php echo session_id(); ?>', '700x500', 'toolbar=no, status=no, scrollbars=yes, location=no, menubar=no, directories=no, width=700, height=500');



----popup.php----

<?php

session_id(strip_tags($_GET['sid']));

session_start();

//and go on with your session vars

?>


workaround when using session variables in a .php file referred by a frame (.html, or other file type) at a different server than the one serving the .php:



Under these conditions IE6 or later silently refuses the session cookie that is attempted to create (either implicitly or explicitly by invoquing session_start()).



As a consequence, your session variable will return an empty value.



According to MS kb, the workaround is to add a header that says your remote .php page will not abuse from the fact that permission has been granted.



Place this header on the .php file that will create/update the session variables you want:



<?php header('P3P: CP="CAO PSA OUR"'); ?>



Regards,

Hugo