<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: Sesiuni în PHP</title>
	<atom:link href="http://www.inphpwetrust.com/sesiuni-in-php/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.inphpwetrust.com/sesiuni-in-php/</link>
	<description>click-click, copy, click-click, paste ...</description>
	<lastBuildDate>Sun, 31 Oct 2010 20:17:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: SaltwaterC</title>
		<link>http://www.inphpwetrust.com/sesiuni-in-php/comment-page-1/#comment-78</link>
		<dc:creator>SaltwaterC</dc:creator>
		<pubDate>Mon, 29 Mar 2010 20:32:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=149#comment-78</guid>
		<description>Dezavantajul deschiderii sesiunii în mod explicit se poate evita prind arhitectură bine gândită. Cei ce apelează la front controller pattern design sunt acoperiți. Cei cu MVC pot avea un base controller pe care să-l derive (you&#039;ve gotta love OOP). Chiar și mizeriile acelea de scripturi independente pot avea un init inclus, dar să-i ierte Dumnezeu pe cei ce vor avea nevoie de reguli de rewrite în acest caz.

În rest, recomand session.use_only_cookies setat pe 1. În mod &quot;tradițional&quot; PHP-ul era vulnerabil la session fixation trimis prin GET (cacalamal.php?SESSIONID=[insert coin to continue]) și se prea poate să mai fie, dar n-am testat, la mine 1 e implicit. Deasemenea n-ar strica session.cookie_httponly pentru cei cu PHP 5.2.0+ pentru că poate evita citirea cookie-ului ce conține Session ID-ul prin metode XSS pe browserele ce respectă flag-ul respectiv și pentru XmlHttpRequest, unde cele bazate pe Gecko sunt acoperite de ceva vreme.

Printre altele, legat de exemplul de cod din articol, recomand ca flag-urile de autentificare (cum e acel $_SESSION[&#039;isLogged&#039;] = true;) să fie verificare corect.

if ($_SESSION[&#039;isLogged&#039;])

nu e tot una cu

if ($_SESSION[&#039;isLogged&#039;] === true)

chiar dacă pentru valoarea true se evaluează la fel. În plus, nu recomand ca autentificarea să se facă pe bază de sesiune, ci mai degrabă prin cookie trimis doar prin conexiune SSL, dacă se poate (în general nu se poate SSL pe shared hosts datorită arhitecturii proaste Apache + mod_ssl și pentru faptul că majoritatea oricum fac oversell pe shared), iar verificarea datelor de autentificare să se facă la fiecare cerere. Da, e un &quot;overhead&quot; acolo, dar modelul acesta &quot;stateful&quot; pentru autentificare a ridicat suficiente probleme de securitate de-alungul istoriei.

Ac6um eu știu că acest articol este dedicat începătorilor, dar o trântesc aici ca să nu mai umplu alte pagini de comentarii: începătorii de azi, coderii de mâine. PHP conduce detașat la capitotlul &quot;web security issues&quot; pentru un motiv anume: cred că 90% din cei ce se auto-intitulează &quot;PHP coders&quot; sunt pastă, Joomla groupies programmers wannabes. Pentru cei ce au ceva de obiectat la propoziția anterioară, un search pe Secunia este relevant. De cele mai multe ori particula defectă stă între scaun și tastatură din moment ce doar aproximativ 1% din problemele de securitate ale PHP sunt generate de către nucleul limbajului. Deci încă de la început ar trebui ca lucrurile să fie făcute bine. Eu inițial le-am învățat prost și a trebuit să depun eforturi substanțiale pentru a uita mizeriie învățate în școală legate de PHP.</description>
		<content:encoded><![CDATA[<p>Dezavantajul deschiderii sesiunii în mod explicit se poate evita prind arhitectură bine gândită. Cei ce apelează la front controller pattern design sunt acoperiți. Cei cu MVC pot avea un base controller pe care să-l derive (you&#8217;ve gotta love OOP). Chiar și mizeriile acelea de scripturi independente pot avea un init inclus, dar să-i ierte Dumnezeu pe cei ce vor avea nevoie de reguli de rewrite în acest caz.</p>
<p>În rest, recomand session.use_only_cookies setat pe 1. În mod &#8220;tradițional&#8221; PHP-ul era vulnerabil la session fixation trimis prin GET (cacalamal.php?SESSIONID=[insert coin to continue]) și se prea poate să mai fie, dar n-am testat, la mine 1 e implicit. Deasemenea n-ar strica session.cookie_httponly pentru cei cu PHP 5.2.0+ pentru că poate evita citirea cookie-ului ce conține Session ID-ul prin metode XSS pe browserele ce respectă flag-ul respectiv și pentru XmlHttpRequest, unde cele bazate pe Gecko sunt acoperite de ceva vreme.</p>
<p>Printre altele, legat de exemplul de cod din articol, recomand ca flag-urile de autentificare (cum e acel $_SESSION['isLogged'] = true<img src='http://www.inphpwetrust.com/wp-content/plugins/ym_smilies/images/yahoo_wink.gif' alt='&#59;&#41; ' class='wp-smiley' width='18' height='18' title='&#59;&#41; ' /> să fie verificare corect.</p>
<p>if ($_SESSION['isLogged'])</p>
<p>nu e tot una cu</p>
<p>if ($_SESSION['isLogged'] === true)</p>
<p>chiar dacă pentru valoarea true se evaluează la fel. În plus, nu recomand ca autentificarea să se facă pe bază de sesiune, ci mai degrabă prin cookie trimis doar prin conexiune SSL, dacă se poate (în general nu se poate SSL pe shared hosts datorită arhitecturii proaste Apache + mod_ssl și pentru faptul că majoritatea oricum fac oversell pe shared), iar verificarea datelor de autentificare să se facă la fiecare cerere. Da, e un &#8220;overhead&#8221; acolo, dar modelul acesta &#8220;stateful&#8221; pentru autentificare a ridicat suficiente probleme de securitate de-alungul istoriei.</p>
<p>Ac6um eu știu că acest articol este dedicat începătorilor, dar o trântesc aici ca să nu mai umplu alte pagini de comentarii: începătorii de azi, coderii de mâine. PHP conduce detașat la capitotlul &#8220;web security issues&#8221; pentru un motiv anume: cred că 90% din cei ce se auto-intitulează &#8220;PHP coders&#8221; sunt pastă, Joomla groupies programmers wannabes. Pentru cei ce au ceva de obiectat la propoziția anterioară, un search pe Secunia este relevant. De cele mai multe ori particula defectă stă între scaun și tastatură din moment ce doar aproximativ 1% din problemele de securitate ale PHP sunt generate de către nucleul limbajului. Deci încă de la început ar trebui ca lucrurile să fie făcute bine. Eu inițial le-am învățat prost și a trebuit să depun eforturi substanțiale pentru a uita mizeriie învățate în școală legate de PHP.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mbe</title>
		<link>http://www.inphpwetrust.com/sesiuni-in-php/comment-page-1/#comment-27</link>
		<dc:creator>mbe</dc:creator>
		<pubDate>Thu, 06 Nov 2008 08:45:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=149#comment-27</guid>
		<description>foarte bun articolul, dear cico ai explicat in 2 vorbe ceea ce tot cautam sa aflu de ceva timp...

ps: in god we trust! everything else must have md5 checksum! :P</description>
		<content:encoded><![CDATA[<p>foarte bun articolul, dear cico ai explicat in 2 vorbe ceea ce tot cautam sa aflu de ceva timp&#8230;</p>
<p>ps: in god we trust! everything else must have md5 checksum! <img src='http://www.inphpwetrust.com/wp-content/plugins/ym_smilies/images/yahoo_tongue.gif' alt='&#58;&#80; ' class='wp-smiley' width='18' height='18' title='&#58;&#80; ' /></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: george</title>
		<link>http://www.inphpwetrust.com/sesiuni-in-php/comment-page-1/#comment-15</link>
		<dc:creator>george</dc:creator>
		<pubDate>Sat, 18 Oct 2008 16:07:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=149#comment-15</guid>
		<description>Aşa cum am afirmat în articol funcţia session_destroy() va şterge &lt;b&gt;datele&lt;/b&gt; din sesiune, nu sesiunea în sine. Sesiunea va exista în continuare şi poate fi folosită normal</description>
		<content:encoded><![CDATA[<p>Aşa cum am afirmat în articol funcţia session_destroy() va şterge <b>datele</b> din sesiune, nu sesiunea în sine. Sesiunea va exista în continuare şi poate fi folosită normal</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: theheartcollector</title>
		<link>http://www.inphpwetrust.com/sesiuni-in-php/comment-page-1/#comment-14</link>
		<dc:creator>theheartcollector</dc:creator>
		<pubDate>Sat, 18 Oct 2008 16:03:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.inphpwetrust.com/?p=149#comment-14</guid>
		<description>Salut.

Am si eu o nelamurire: Daca apelez funcia session_start() si apoi scot niste informatii din variabila $_SESSION trebuie apoi sa apelez functia session_destroy() sau se apeleaza singura cand se termina scriptul? Din ce am inteles eu, aceasta functie este inversul functiei session_start(), deci nu distruge si continutul variabilei $_SESSION... Ca sa sterg date din $_SESSION, eu am folosit unset($SESSION(&#039;whatever&#039;)).

PS: Poate reusesti sa scrii un articol mai detaliat despre sesiuni si despre restul functiilor PHP legate de acestea...</description>
		<content:encoded><![CDATA[<p>Salut.</p>
<p>Am si eu o nelamurire: Daca apelez funcia session_start() si apoi scot niste informatii din variabila $_SESSION trebuie apoi sa apelez functia session_destroy() sau se apeleaza singura cand se termina scriptul? Din ce am inteles eu, aceasta functie este inversul functiei session_start(), deci nu distruge si continutul variabilei $_SESSION&#8230; Ca sa sterg date din $_SESSION, eu am folosit unset($SESSION(&#8216;whatever&#8217;)).</p>
<p>PS: Poate reusesti sa scrii un articol mai detaliat despre sesiuni si despre restul functiilor PHP legate de acestea&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

