mod_rewrite sayesinde sayfalarımızın adreslerini istediğimiz formda gösterebiliyoruz (İlgili makale için:http://mfyz.com/htaccess-yardimiyla-tum-trafigi-te......n-yonetmek). Kullanımı çok yaygınlaşsa da bu kullanımın bazı ufak problemleri beraberinde getirdiği göz önünde bulundurulmalı.

Bu yazıda iki çok açık problemden ve basit çözümlerinden bahsedeceğim.

İlk problemlerden birisi sayfanızda kullandığınız tüm medya veya eklentilerin yollarını domain seviyesinden belirtmek durumunda olmanızdır. Eğer htmlinizi yazarken sayfanızdaki görselleri, stilleri, scriptleri bu şekilde tanımlamadıysanız tüm sayfalarınızdaki yolları güncellemeniz gerekiyor.

Basit bir örnekle, ana dizinde duran bir index.php veya html dosyanızın olduğunuz varsayalım ve images, css ve js olarak 3 medya dizininiz olsun. html'inizi kodlarken yolları su şekilde belirtmeniz dogal:
<html>
	<head>
		<title>Blah blah</title>
		<link rel="stylesheet" href="css/style.css" />
		<script src="js/myscript.js"></script>
	</head>
	<body>
		<div>
			<h1>Test page</h1>
			
			<img src="images/cat.jpg" alt="Cat" />
		</div>
	</body>
</html>
Eğer bu uygulmanızda bu sayfayı sunan kodu domain.com/about/license gibi, birden fazla derinlikte bir url ile sunduğunuz zaman, tarayıcınız o sayfa kodunun /about/ dizininde çalıştığını varsayarak medya dosyalarınızı /about/js/, /about/images/ gibi dizinlerde arayacaktır.

Çözümü ise basit. İki seçeneğiniz var bu noktada. Her medya yolunu belirtirkenhttp://domain/images/cat.jpg şeklinde tam yolu belirtebilirsiniz veya dosya/dizin yollarını belirtirken "/" işareti ile başlayarak domain seviyesinden itibaren işaret edeceksiniz yollarınızı yani yukarıdaki html kodunda her yol tanımlamasını "/" işareti ile başlayarak (ekleyerek) düzeltebilirsiniz.

Başında bir protokol ile belirtilmemiş her url domain üstündeki bir yolu ifade eder. "/" işareti ile başlayan yollar ise domain seviyesini işaret eder. Yani sadece "/" şeklinde tanımlanmış bir link aslında domain ana dizinini işaret eder. Ama bizim amacımız domain seviyesinden itibaren bir dizini işaretlemek, dolayısıyla /images/icons/plus.png gibi bir yol sızı nerede olursanız olur her zamanhttp://domain.com/images/icons/plus.png'yi işaret ederek istediğiniz dosyaya ulaştıracaktır.

Cookie Problemi

Bir diğer problem ise çerez (cookie) problemidir. Çerezlerin tarayıcıda kaydedildiğini hatırlamakta fayda var. Sunucu tarafında dahi çerez kaydetmek isteseniz o çerez aslında o isteğin cevabında gelen headerlar'da olacak ve tarayıcı istek cevabındaki değerlere göre çerezleri kaydedecek, silecek veya güncelleyecektir. Yani tarayıcının çerezleri yönettiğini bilmeniz gerekiyor, ayrıca çerezlerin dizin bağımlı olduklarını da belirtmek gerek. Yani bir çerezi /A/B/C dizininde iken ayarlarsanız bu çerez sadece C dizini ve alt dizinlerinden erişilebilir olacaktır. C dizinindeyken aryıca ana dizin, A ve B dizininde kaydedilmiş çerezlere de erişebilirsiniz. Tarayıcı, alt dizinlerdeki bir çereze erişimi bir üst dizinden veya paraleldeki bir dizinden vermez.

Bu durumda url'lerinizi klasör şeklinde ayarladıktan sonra uygulamanızda nerelerde çerez kaydediyor, siliyor veya güncelliyor olduğunuzu hatırlamanız ve güncellemeniz gerekiyor. Bu güncellemeyi hem javascript'deki cookie kullanımınız için hem de sunucu tarafındaki çerez kullanımınız için güncellemeniz gerekiyor. Sunucu tarafında bütün dillerde çok bilinen bir problem olduğu için yazdığınız sunucu taraflı dile ilişkin çerez methodlarını inceleyin. Ben kısaca php'de nasıl yapacağınızı anlatacağım.

Önce javascript ile çerez işlemlerinizi güncellemek için, normalde kullandığınız:
document.cookie = "";
koduna ek olarak "path=/" eklemeniz gerekecektir (tabi ki ; ayracını kullanarak diğer çerez cümlenize ekleyebilirsiniz.

Bu size karışık gelmiş olabilir çünkü javascript ile çerez yönetimini herhangi bir kütüphane kullanmadan yapmanın yolu bu. Ancak muhtemelen jquery veya en azından çerezlerinizi okumak, silmek veya kaydetmek için bir kütüpahne kullanıyor iseniz kullandığınız kütüpahenin "path" yani çerez dizinini belirtebileceğiniz bir yöntemi vardır, bu yöntemi uygulayarak tüm çerezlerinizi ana dizininizde ayarlamalısınız, böylece çerezleriniz her yerden erişilebilir hale geleceklerdir.

PHP'de bu problemi çözmek için tüm "setcookie" fonksiyonunun (name, value, expire) standart kullanımına 4. parametre olarak "/" yani dizin parametresi eklemeniz yeterli olacaktır. Bu noktadan sonra kaydettiğiniz tüm çerezler ana dizine kaydedilecek, böylece her yerden erişilebilir hale geleceklerdir.


Bu konu, daha teknik noktalarda başka problemleri de beraberinde getiriyor fakat url'lerinizi klasör şeklinde ayarladıktan sonra ilk karşılaşacağınız iki büyük problemden ve çözümünden kısaca bahsetmiş oldum.


Hazırlayan: Mehmet Fatih YILDIZ
Website optimizasyonu konusu büyüyen startupların artık başta düşünmeye ve endişe duymaya başladığı bir konu. Bir web sayfasının optimizasyonu konusunda birçok detaycı yaklaşım var, bunlardan birisinden bahsedeceğim şimdi.

Web sayfanızda sayfa dışında yüklediğiniz bir çok dosya var. Bunlar genellikle imajlar, css ve javascript dosyaları. Tabi bunun dışında flash nesneleri, activex nesneleri, java nesneleri gibi başka dosyalar da olabilir. Bu dosyaları tarayıcı sunucudan isterken eğer domain cookie açık bir domain ise her istekte sunucunuza, istemcinizdeki cookie içerikleriniz gönderilir. Aynı şekilde sunucu da size gönderir.

Eğer o domainde çalıştırdığınız uygulamanız çok cookie set etmemişse bu konunun çok önemi olmaz ancak uygulama geliştiricinin ne yaptığını bilemezsiniz ve uygulama geliştirici de bu konuyu düşünerek "daha az cookie set etmeliyim" yaklaşımı ile uygulama geliştirmez. Yani eğer çok cookie barındırıyorsanız veya cookie içerikleriniz büyükse (mesela bir formun state'inin encode edip büyük bir text olarak saklıyor olabilirsiniz) bu imaj (js, css) transerlerinde bir de bu cookieler gönderilip alınacağından belli sayıda dosyadan kayda değer bir yavaşlama hissedilecektir.

Özellikle .NET'deki authentication cookie'leri gibi büyük boyutlu cookie saklayan uygulamalarda, eğer http request sayınız çok ise bu yavaşlama hissedilir derecede olabilir.

Bunu engellemek için uygulamanızı sunduğunuz domain ile bu statik dosyaları sunduğunuz sunucuyu ayırmalısınız. Sunucuyu ayırmaktan kastım fiziksel olarak ayırmak değil. Mesela mfyz.com domaini için konuşursam, uygulama mfyz.com üzerinde çalışıyor ve kullanıcı bu domainden girip burada kalıyor. Ama bununla beraber gelen birçok statik dosya cookie disabled bir subdomainden sunulabilir. Mesela statik.mfyz.com gibi bir subdomainden sunulurken, uygulamada header'da include ettiğim bir js dosyası için
<script type="text/javascript" src="http://mfyz.com/js/main.js"></script>
yerine
<script type="text/javascript" src="http://statik.mfyz.com/js/main.js"></script>
kullanmam yeterli olacaktır.

Gelen giden trafikte cookie'ler gönderilmeyeceğinden ve alınmayacağından transfer boyutları azalacaktır. Bu değişim birkaç dosyada bir anlam taşımayacaktır ama çok dosyada anlamlı olabilir.

Dediğim gibi çok detay bir konu ama yapmasanız da böyle bir faktör olduğunu bilmelisiniz.
3 Haziran Cuma ´05   —   4 Yorum

Bunlar nedir ne işe yarar?

PHP'de aslında dinamizmi getiren çoğu şeye karşılık kullanıcının hareketlerini izlerken veya kullanıcının hareketlerine karşı kodumuzun vermesini istediğimiz tepkileri belirlerken kullanıcı taraflı bilgi saklamaya ihtiyaç duyuyoruz. Sonuçta bütün olay sunucuda veya kullanıcıda bitmiyor. İkisinin iyi senkronu ile iyi koda dayanıyor.

Cookie de session da aynı yapıdadır. Basit olarak olay session'u cookie'ye benzeterek anlatmakla daha rahat anlaşılacaktır.
Cookie'ler kullanıcının bilgisayarında bir meta ve değer olarak tutulan, domainlere göre süzgeçlenen dosyalardır. Yani;
1. Dosya adı vardır ve bellidir.
2. İçeriği o dosyaya ait bilgiyi içerir.
(Normal veriden farklı yani)
3. bu dosyaların ve buna ait bilgilerin silineceği tarih bellidir. Son kullanma tarihi gibi.

Cookie dosyaları zamanı geldiğinde silinen değişkene benzer veri taşıma methodudur. Kullanıcı tarafında taşındığı için günevli olmayıp, kodlarda içeriği zararlı veriler taşınmamalıdır. Mesela bir üye sisteminde cookie içinde kullanıcının şifresi taşınmaz. Ancak oturum id'si kullanıcı id'si gibi bilgiler taşınmalıdır.

Session ise cookie'ler gibi çalışır, ancak bu bilgilerin silineceği zaman kullanıcının oturumu sonlandırdığı andır. Yani bu verilerin yönetimini zamanla sağlamayız. Oturum dedğimiz şey ise tarayıcı programa göre değişir. Bazı programlar bulunduğu pencereye ait oturumu taban alır. bu tarayıcılarda bir oturuma ait sitedeki pencerelerin hepsi kapanınca oturum kapanmış olur. Bazı tarayıcılarda ise tarayıcı program ve onunla ilişkili process kalamyana kadar ortak bir oturum çerçevesinde gider.

Peki bunları nerelerde kullanırız?

Cookie'ler belirli bir tarihe göre silinirler.. Uzun vadeli kullanıcı taraflı veri saklarken cookie'ler biçilmiş kaftandır. Ancak kısa vadeli (3-5 dakikalık veriler için, mesela oturum yönetimi için) pek güvenilir olamayabilir. Bunun için session (adı üstünde zaten "oturum") kullanılır. Bir üye sistemi için cookie kullanılırsa, örneğin internet cafe'deki acil çıkışlarda masaya oturan diğer kişi bulduğu tarayıcı pencerelerini kurcalarken yanlış şeyler yapabilir..
Anket veya ziyaret kontrollerinde cookie'ler gayet güzel çalışabilirler.
Şu an dökümanlar bölümünde listelere dikkat ettiyseniz, listelerdeki dökümanların başındaki turuncu oklar renk değişimi gösterecektir. Okuduğunuz dökümanlar cookieler sayesinde orada daha flu bir renge dönüşecek ve okumadığınız, yeni dökümanları daha rahat seçebileceksiniz. Bu cookie sayesinde oluyor. Ama kullanıcı girişi çıkışı session + cookie karışımı ile.
Beni hatırla seçeneği ile bilgisayarınız bir kod yazılıyor. bu kod veritabanındaki hatırlama kodunuzla karşılaştırılıp eşlenmesi halinde otomatik giriş sağlanıyor. Tabiki bu kod yeterince güvenli. Çözebilen var ise artık girip istediğini yapsın. Zaten kodu kırmakla haketmiş :-)

Bu alanda yapılan yanlışlar ve güvenlik sorunları!!

- Çoğu php'ye yeni başlayan cookie'leri önce öğrenip, ilk giriştikleri üye sisteminde cookie ile yazıyor. Burası yanlışın başlangıcı.
- Yine çoğu yeni başlayan php programcıları üye sistemlerinde cookie veya session değişkenlerinin içine tek kontrol ile kullanıcı adı veya kullanıcı adı + şifre saklıyor.. Yanlışın 1 numaralısıdır bu..
Exploitler ile bu açıklar kolaylıkla aşılabilir.

"Hangisi" değil "Nasıl"?

Ne kullandığınız değil, nasıl kullandığınız önemlidir. Belki üye sistemi session yerine cookie ile daha sağlıklıdır. Nerede kullandığınız da çok önemli bir unsurdur. Mesela bir banka sitesini yapıyorsanız Session kontrollü cookie tabanlı bir yapı çok daha sağlam olur. vs vs..


Hazırlayan : Mehmet Fatih YILDIZ

Popüler Etiketler

firefox apple macosx license xml nedir internet statistics html5 mobile browsers table job xhtml css php javascript wanda digital iphone ipad newsletter mail jquery link plugin kontrol yapıları if while wordpress rss wireless optimizasyon örnek kod export ubuntu cache konsol terminal subscription api google social media service startups music ie browser dokuman blog js switch gimp twitter widget auth http developer mfyz download istatistik sosyal medya htaccess url ios app store store in-app purchase purchase verification storekit itunes connect itunes imza html signature facebook connect search ajax meta share mootools www subdomain redirect crossdomain sitemap generator workspace ide editor phpstorm jetbrains deployment version control svn git less howto network app pear mdb2 prepare execute mysql mssql pgsql portfolio css3 language development style ruffles oyun integration server chart osx applications free framework apache route router mod_rewrite seo compile tool kurulum subversion proje assets spam internet explorer cms logo screen form input textarea select graph windows linux fstab ntfs doritos kampanya tytz iOS calendar sql support code object cookie ui ux login webkit injection notebook laptop lisans pharma hack banner db database compiler on-the-fly web app open source date tarih query regex nasıl opengraph fql optimization grafik box design diff zaman bootstrap lifestream radio parse player ipucu insanlar analyse procedure session xmlhttprequest tebrik icon ikon kitap button icons coding