<?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/"
		>
<channel>
	<title>Commentaires sur : Persistance des données</title>
	<atom:link href="http://didiode.fr/wp/2011/03/persistance-des-donnees/feed/" rel="self" type="application/rss+xml" />
	<link>http://didiode.fr/wp/2011/03/persistance-des-donnees/</link>
	<description>Internet &#38; Outils, Paris-Diderot</description>
	<lastBuildDate>Thu, 20 Feb 2025 09:37:38 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.5</generator>
	<item>
		<title>Par : Baptiste F</title>
		<link>http://didiode.fr/wp/2011/03/persistance-des-donnees/#comment-609</link>
		<dc:creator>Baptiste F</dc:creator>
		<pubDate>Fri, 15 Apr 2011 11:57:56 +0000</pubDate>
		<guid isPermaLink="false">http://didiode.fr/wp/?p=229#comment-609</guid>
		<description>À propos des sessions (désolé du doublon), elles ne sont pas sécurisées à 100%. Les informations sont certes stockées sur le serveur, mais pour associer chaque session à chaque visiteur, un cookie contenant une ID unique de session est créé chez le client, et là est le problème, puisqu&#039;il &quot;suffit&quot; de falsifier son cookie en prenant l&#039;ID de session de quelqu&#039;un d&#039;autre (encore faut-il le trouver, mais ce n&#039;est pas impossible) pour avoir son identité aux yeux du serveur. La seule solution reste le chiffrement de connexion.

&lt;a href=&quot;http://www.php.net/manual/fr/session.security.php&quot; rel=&quot;nofollow&quot;&gt;Plus d&#039;infos ici&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>À propos des sessions (désolé du doublon), elles ne sont pas sécurisées à 100%. Les informations sont certes stockées sur le serveur, mais pour associer chaque session à chaque visiteur, un cookie contenant une ID unique de session est créé chez le client, et là est le problème, puisqu&#8217;il &laquo;&nbsp;suffit&nbsp;&raquo; de falsifier son cookie en prenant l&#8217;ID de session de quelqu&#8217;un d&#8217;autre (encore faut-il le trouver, mais ce n&#8217;est pas impossible) pour avoir son identité aux yeux du serveur. La seule solution reste le chiffrement de connexion.</p>
<p><a href="http://www.php.net/manual/fr/session.security.php">Plus d&#8217;infos ici</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Par : Baptiste F</title>
		<link>http://didiode.fr/wp/2011/03/persistance-des-donnees/#comment-606</link>
		<dc:creator>Baptiste F</dc:creator>
		<pubDate>Fri, 15 Apr 2011 08:10:37 +0000</pubDate>
		<guid isPermaLink="false">http://didiode.fr/wp/?p=229#comment-606</guid>
		<description>Avec l&#039;arrivée d&#039;HTML5, une troisième méthode de stockage d&#039;informations est disponible: le &lt;a href=&quot;http://dev.w3.org/html5/webstorage/&quot; rel=&quot;nofollow&quot;&gt;localStorage&lt;/a&gt;.
&lt;a href=&quot;http://www.lafermeduweb.net/billet/le-stockage-local-en-html5-localstorage-942.html&quot; title=&quot;Le stockage local avec HTML5&quot; rel=&quot;nofollow&quot;&gt;Plus d&#039;informations&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>Avec l&#8217;arrivée d&#8217;HTML5, une troisième méthode de stockage d&#8217;informations est disponible: le <a href="http://dev.w3.org/html5/webstorage/">localStorage</a>.<br />
<a href="http://www.lafermeduweb.net/billet/le-stockage-local-en-html5-localstorage-942.html" title="Le stockage local avec HTML5">Plus d&#8217;informations</a>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
