<?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>Comments on: Ajax zorgt voor veiligheids en bereikbaarheids problemen</title>
	<atom:link href="http://www.usabilityweb.nl/2006/01/ajax-zorgt-voor-veiligheids-en-bereikbaarheids-problemen/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.usabilityweb.nl/2006/01/ajax-zorgt-voor-veiligheids-en-bereikbaarheids-problemen/</link>
	<description>Kennisbank voor gebruikersvriendelijke websites</description>
	<lastBuildDate>Mon, 07 Nov 2011 09:21:40 +0100</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Tobi</title>
		<link>http://www.usabilityweb.nl/2006/01/ajax-zorgt-voor-veiligheids-en-bereikbaarheids-problemen/comment-page-1/#comment-2137</link>
		<dc:creator>Tobi</dc:creator>
		<pubDate>Tue, 31 Jan 2006 14:48:35 +0000</pubDate>
		<guid isPermaLink="false">http://localhost/Werk/usabilityweb.nl/wordpress_clean/2006/01/ajax-zorgt-voor-veiligheids-en-bereikbaarheids-problemen/#comment-2137</guid>
		<description>Volgens mij zijn de risico&#039;s hetzelfde als bij een standaard webinterface. Invoer moet je controleren. Doordat de communicatie complexer wordt moet je hier inderdaad wat meer tijd aan besteden.

&quot;Met Ajax verplaats je bedrijfslogica van de server naar de client&quot;
Als je er vanuit gaat dat &#039;de client&#039; alles naar je server kan sturen lijkt het me niet verstandig de bedrijfslogica bij de client neer te leggen. Dat is vragen om problemen. (Ik wil graag 10 iPods a €0,01 per stuk.) Een minimaal deel van de logica naar de client kopiëren om de gebruikerservaring te verbeteren lijkt me het hoogst haalbare.

Interactie op een reguliere website is in het praktijk het gevaarlijkste wat je kunt doen. Ook grote websites worden nog regelmatig aangepakt met hele simpele truckjes. AJAX is nu nog pionieren maar als er naar verloop van tijd goede applicatie-frameworks ontstaan kunnen die de beveiliging voor een groot deel op zich nemen waarbij je het risico juist verkleint.</description>
		<content:encoded><![CDATA[<p>Volgens mij zijn de risico&#8217;s hetzelfde als bij een standaard webinterface. Invoer moet je controleren. Doordat de communicatie complexer wordt moet je hier inderdaad wat meer tijd aan besteden.</p>
<p>&#8220;Met Ajax verplaats je bedrijfslogica van de server naar de client&#8221;<br />
Als je er vanuit gaat dat &#8216;de client&#8217; alles naar je server kan sturen lijkt het me niet verstandig de bedrijfslogica bij de client neer te leggen. Dat is vragen om problemen. (Ik wil graag 10 iPods a €0,01 per stuk.) Een minimaal deel van de logica naar de client kopiëren om de gebruikerservaring te verbeteren lijkt me het hoogst haalbare.</p>
<p>Interactie op een reguliere website is in het praktijk het gevaarlijkste wat je kunt doen. Ook grote websites worden nog regelmatig aangepakt met hele simpele truckjes. AJAX is nu nog pionieren maar als er naar verloop van tijd goede applicatie-frameworks ontstaan kunnen die de beveiliging voor een groot deel op zich nemen waarbij je het risico juist verkleint.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

