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

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