Session’ları Memcached’te Saklamak Ne Kadar Doğru?

Özellikle arkasında birden fazla web sunucusunun bulunduğu web projelerinde genellikle non-sticky session bilgilerini saklamak için Memcached kullanılır. Bu şekilde kullanıcıların, farklı web makinelerine düştüklerinde oturum bilgilerine erişilebilmesi amaçlanır.

Ama projenizde her şey yolunda giderken, bir anda kullanıcılardan kendi istekleri dışında “logout olma” şikayetleri gelmeye başladı. Hemen projenizin kodlarını incelediniz ancak anormal bir durum görünmüyor.

Muhtemelen Memcached kullanıcıların session bilgilerini siliyordur.

Peki ama nasıl?

Bu durumu örneklersek: 1. kullanıcı giriş yaptı ve session bilgileri Memcached‘e yazıldı. Ardından yüzlerce kullanıcı da giriş yaptı ve hafızada yer kalmadı. 1. kullanıcının session bilgileri silindi ve böylece logout oldu.

Memcached neden session bilgilerini sildi?

Memcached’e 64 MB (örnek değer) limit verdiniz ve bu 64 MB doldu. Memcached otomatik olarak kendi içerisinde LRU (Least Recently Used) algoritmasını uygulamaya başlayacaktır. Bu algoritma ile “son zamanlarda en az kullanılan” key’i hafızadan silecektir.

Bu senaryoda da bizim silinen key’imiz 1. kullanıcının session key’i oluyor.

Bir diğer durum ise Memcached persistent (kalıcı) bir veri saklamaması. Bundan dolayı sadece LRU algoritması ile değil herhangi bir sebepten dolayı Memcached kapanıp, yeniden açılırsa da (konfigürasyon değişikliği, işletim sisteminin yeniden başlatılması, donanım güncellemesi vs.) session bilgileri silinmiş olur. Doğal olarak kullanıcılar web sitesinden çıkış yapmış olur. Bu da kimi projeler için hoş olmayan sonuçlar doğurabilir.

Session kayıplarını önlemek için, genelde persistent şekilde veri saklayan RDBMS, NoSQL çözümler kullanmanız önerilir.

Bir yazıda hem session hem cache geçiyorsa sonuna şu gif’i koymamak olmaz :) : Patronun cache icin session kullandigini gordugumde ben

 
71 Kudos
Don't move

İmzalamadığınız Commit Sizin Değildir

Git kullananlar bilirler, .gitconfig isimli dosyaya isim soyisim ve e-posta adresi yazılarak commit loglarına commit sahibinin bilgileri otomatik eklenir.

Ancak bu durumun bir olumsuz(?) yanı vardır. Başkaları sizin adınıza commit yapabilir.
Kendi .gitconfig dosyanıza Ali yazsanız Ali’nin adına Veli yazsanız Veli’nin adına commit yapabilirsiniz.

Ancak bir commit’in gerçekten o kişinin yaptığına emin olmak için commit’i imzalamakta fayda vardır.

Peki imzalamayı nasıl yapacağız?

Öncelikle sisteminizde imza var mı bakınız:

gpg --list-keys

(Eğer daha önce GPG ile ilgili işlem yapmamışsanız, bu komut gerekli dosyaları da oluşturacaktır.)

Şuna benzer bir sonuç döndürmeli:

pub   2048R/B489436C 2014-12-14
uid                  Adil Ilhan <no-reply@adililhan.com>

Eğer GPG anahtarınız yoksa boş sonuç dönecektir.

gpg --gen-key

komutu ile GPG anahtarınızı oluşturabilirsiniz. Bu komut size yol gösterecektir.

Ekstra olarak açıklama gereği duyduğum kısım passphrase kısmı. Buraya parola girerseniz oluşturacağınız anahtar bu parola olmadan çalışmayacaktır. Yani anahtarınız çalınsa bile ekstra olarak bir de buraya yazdığınız parolaya ihtiyaç duyulacaktr.

GPG anahtarı artık oluşmuş olmalı. Kontrol için:

gpg --list-keys

Git ortamınıza bu anahtarı tanımlamak gerek:

git config --global user.signingkey B489436C

B489436C bilgisini gpg –list-keys komutunun sonucundan aldım.

Artık commitleri -S parametresi ile imzalayabiliriz:

git commit -m "test" -S

İmzalanmış commitleri görme ve doğruluğunu teyit etme:

git log --show-signature

Bu komut, yerel (local) makinenizdeki GPG bilgisi ile commit log’unda yer alan GPG bilgisini eşleştirir.
Uyuşan loglara gpg: Good signature… yazılır. Uyuşmayan loglara Can’t check signature yazılır.

Örneğin sizin bilgisayarınızdan imzalanarak commitlenen bir commit başka bir bilgisayarda bakıldığında ve o bilgisayarda sizin GPG anahtarınız yoksa log sonuçlarına Can’t check signature bilgisi yazılır.

 
17 Kudos
Don't move

Özgür Web Teknolojileri Günleri 2014 / Composer ile PHP’de Bağımlılık Yönetimi

6 Aralık 2014 tarihinde İstanbul, Yeditepe Üniversitesi 26 Ağustos Kampüsü’nde gerçekleşen Özgür Web Teknolojileri Günleri 2014 etkinliğinde yaptığım “Composer ile PHP’de Bağımlılık Yönetimi” isimli sunumun dosyası aşağıdadır.

 
6 Kudos
Don't move