ViewState, EventValidation POSTBACK olayı hk.

[mrmarman]

Merhaba..

- WEB tabanlı sorguları Delphi'den yapmak ve sonuçlarını almak konusunda oldukça deneyimim oldu.

- WEB olayına aşina olmakla birlikte, teknik detay konusunda sıkıntı yaşıyorum. ViewState ve EventValidation kavramını bilen varsa soracağım soru çerçevesinde kısaca değinirse sevinirim.

1. Cookies Kavramı : Her cookie için mutlaka bilgisayarımızda oturum açtığımız USER altındaki Cookies klasöründe text tabanlı bir dosya açılarak yazılıyor mu Yoksa hafızada tek SESSION bazında geçici konumlanma durumu olabiliyor mu

- SESSION bilgisini almak için bunu IdCookieManager'dan yararlanıyorum.

- Sorumun amacı; Cookie'leri engellemek için Internet Ayarlarında Güvenliği üst düzeye çıkardığım ve sitedeki ViewState ve EventValidation değerlerine blok koyduğum (HDD'den okuduğum statik değerleri post sırasında vererek) halde browse ettiğim sitedeki, bir yerlere sakladığı veriyi değiştirmediğimden sonuç alamamam üzerine.

- Acaba diyorum, RAM'de session açık olduğu sürece tutulan bir geçici veri saklama konumu mu var İllaki var ama bu da mı Cookie'dir Saklanabilir mi ? IdCookieManager benzeri bir yöntemle okunabilir mi

2. POST edilen değerler kodlanıp ViewState ve EventValidation verisi oluşturuluyor.

- ViewState ve EventValidation'u görev olarak birbirinden ayıran nedir
- Ortak noktaları nedir ?
- Birbirleriyle eş güdümlü buludurmaları gereken içerik veri var mıdır

- İlgilenen herkese teşekkürler...

[MercilessTurk]

1. Cookies Kavramı : Her cookie için mutlaka bilgisayarımızda oturum açtığımız USER altındaki Cookies klasöründe text tabanlı bir dosya açılarak yazılıyor mu Yoksa hafızada tek SESSION bazında geçici konumlanma durumu olabiliyor mu

- SESSION bilgisini almak için bunu IdCookieManager'dan yararlanıyorum.

- Sorumun amacı; Cookie'leri engellemek için Internet Ayarlarında Güvenliği üst düzeye çıkardığım ve sitedeki ViewState ve EventValidation değerlerine blok koyduğum (HDD'den okuduğum statik değerleri post sırasında vererek) halde browse ettiğim sitedeki, bir yerlere sakladığı veriyi değiştirmediğimden sonuç alamamam üzerine.

- Acaba diyorum, RAM'de session açık olduğu sürece tutulan bir geçici veri saklama konumu mu var İllaki var ama bu da mı Cookie'dir Saklanabilir mi ? IdCookieManager benzeri bir yöntemle okunabilir mi

Selam sadece ilk sorunuz hakkında bir iki şey söyleyebilirim. Session ile ilgili herhangi bir cookie kaydedilmiyor hdd ye. Cookie oluşturuluyor fakat kaydedilmiyor. Linux üzerinde firefox kullanıyorum. Firefox üzerindeki bir eklenti sayesinde girdiğim tüm sitelerdeki o anki cookie leri görebiliyorum. Mesala kendi hazırladığım ve cookie olarak sadece üyelik bilgilerini tuttuğum bir php portal sisteminde sadece üyelik bilgilerini değil ayrıca oluşturduğum session bilgilerinide firefox otamatik olarak cookie olarak gösteriyor ama hdd ye kaydetmiyor. Session cookie sinde de sadece PHPSESSID(Session id) değerini tutuyor. Session id tek başına bir anlam ifade etmiyor. Linux sistemlerde bu session id lere ait bilgiler /tmp klasöründe tutuyor ki buraya da ulaşmak servera ulaşma iznimiz olmasını gerektiriyor (diğer web programlama dillerinde ve işletim sistemlerinde nasıl bir yol izleniyor bilmiyorum ama buna benzer yollar izlenildiğini tahmin ediyorum).

Kısaca eğer sorunuzu yanlış anlamadıysam session bilgilerine ulaşma olanağınız yok.

Kolay gelsin.

[mrmarman]

Teşekkürler.

- Session bilgisi detaylarına ulaşamayacağım tamam. Proxy vs. yazmanın dışında (proxy vs. derken gelen paketlerin okunmasından kasıt) şifreli de olsa blok halinde alabilmenin yolu var mıdır sizce ? (Indy bileşenleri, TWebBrowser vs.) Hatta aynı şekilde geriye blok halinde gönderebilsem sorunum hallocak..

- Konu zaten localde geçiyor. Server'in locale gönderdiği bilgiler, SUBMIT esnasında tekrar geriye server'e alınarak kullanıyor olduğunu değerlendiriyorum.

- Bu kanıya nasıl vardım ?! Browse edildiği sırada bilgi girişi yapılıp SUBMIT edildikten sonra sonuç alınıyor. BACK yaptığımda SESSION'da veri varsa "bilgiler güncel değil, veri kaybın olabilir" türevi uyarısı verilir ya. Bu uyarı verilmiyor, sorunsuz eski veriler karşıma yeniden geliyor. Ama hiçbişey yapmadan yeniden SUBMIT edersem bu ikinci seferde "doğru giriş yapılmadığı" uyarısı geliyor.

- Yeri gelmişken amaç; bu geri dönecek server için teyid manasındaki değerlerin kontrol altına alınarak farklı tarihlerde ve farklı sezonda ama aynı veriyle işlem yapabilmek. Bu veriyi çözmek zorunluluğum da yok. Sadece blok halinde geri sunmak kafi.

- Ek - Firefox'un hangi eklentisi acaba ? Sorsam..

Ref : https://addons.mozilla.org/en-US/firefo ... s&status=4

bunlardan en etkin olanı kullandığını varsayarak soruyorum..

[mrmarman]

- Firefox'u seviyorum. CookieSafe 2.0.6 kurdum. Yukarda bahsi geçen sorguyu içeren siteye Permenantly Block dediğimde kesinlikle her zaman yanlış veri girildiği cevabını alıyorum.


- SessionID değişmediği hep sabit olduğu halde her gelen veriye göre değişik yorum yapmasından yola çıkarak görünmeyen veri sözkonusu.

- Son sorum ve diğer hususlarda bilginiz / bilgisi olan varsa memnun olurum..

[mkysoft]

Bildiğim kadarıyla (bu yazıları okumadan önce %100 emindim. cahil cesaretli olurmuş) Session'lara ulaşamazsınız. Çünkü onlar server tarafında tutulan değişkenlerdir. Session_id ise serverin o kullanıcıya ait tuttuğu değişkenlerin adresini gösteriyor sanırım. Normalde sessionid olmadan da hangi bilgi tutabilirsiniz. Hiç bir browser server'ın session tuttuğunu anlamaz.
Session'ların cookilerle de bir bağlantısı yoktur, tabi sessionid gibi bir değişkeni kaydetmezseniz.
session ların timeout süresi vardır. Bu süre dolduğunda iptal olurlar.

Sizin üzerinde uğraştığınız sistemde sanırım yapı şu şekilde: login olduğunuzda yada sayfayı açtığınızda bir session yaratılıyor. sonuç sayfası çalıştığındada bu session kapatılıyor. Geri düğmesine bastığınızda sayfa yeniden yüklenmediğinden session oluşmuyor. Ayrıca şuda olabilir, kullanıcının sorgulama yapıp yapmadığına dairde session kullanabilirler.

Session'lar serverda ip bazlı yada ip header bazlı oluşturuluyordur.

ViewState ve EventValidation olaylarını duymadım. Sanırım ASP.NET içinde geçiyordu. ASP.NET içindede session korumaları var.

Kolay gelsin.

[Fatih!]

http://odetocode.com/Blogs/scott/archiv ... /3153.aspx
http://odetocode.com/Blogs/scott/archiv ... /3145.aspx

viewstate sayfada bulunan nesnelerin son durumunu tutuyor. linktende anladığım kadarıyla eventvalidation olayların tetiklenmesinde istemcide yapılan olası tehlikeleri kontrol ediyor.

[mrmarman]

arkadaşlar, teşekkürler.

- Bu konuya biraz daha çalışayım en iyisi. Sanırım gelen paketleri irdelemem gerekecek.

EK

- @mkysoft her kullanıcı için SessionID server'de tutulacak olursa , timeout süresine kadar inanılmaz bir RAM ihtiyacı olmaz mı ? Mesela sürekli ard arda sorgu yapılıdığını varsayalım. O zaman bu sorum daha gerçekçi olur...

[mkysoft]

O zaman daha fazla RAM'i olan servera geçeceksiniz
Apache içinde her domain için max user ayarı vardır. Bu sayede session ların sınırı belirlenmiş olur.

[mrmarman]

Hocam yanlış anladınız.

- Ben client'im server olanların stratejisini araştırıyoruz.

[lazio]

Cookies

Cookie ler client tarafta text tabanlı dosyalar olarak temporary dizinde tutulurlar. Programcı kontrolünde belirli bir timeout süresi ile atılırlar.
Session ise server tarafında atılır ve her client için unique bir id dir. Ayrıca yine cookie lerde olduğu gibi programcı da birden çok session atabilir.
Session lar içinde değiştirilebilen bir timeout süredi vardır ama genelde süre dikkate alınmaz çünkü browser ın kapanışı zaten session ı öldürür.
ViewState ve EventValidation Asp.net in bir özelliğidir ve doğrudan Session la bir ilgisi yoktur. Session ların bir şekilde okunabildiğini hep duyuyorum ama bunun gerçek bir örneğini görmedim henüz. Zaten teorik olarak server ın bellek alanına erişmek pek mümkün gözükmüyor.

POST edilen değerler kodlanıp ViewState ve EventValidation verisi oluşturuluyor.

View state, sayfayı kendi üzerine defalarca post etmenize rağmen hiç bir işlem yapmadan sayfadaki controllerin değerlerini kaybetmemesidir. yani sayfa post olduktan sonraki yüklemede (onload da) view state e bakarak ilgili değerleri ilgili kontrollere yükler. View State durumu aktif yada pasif olarak değiştirilebilir.
EventValidation da aktif yada pasif yapılabilen bir form doğrulama mekanizmasıdır. Örneğin bir bir text box içindeki html tag ları post etmeye çalıştığınızda devreye girerek exception fırlatacaktır. Bildiğim kadarıyla View State ile doğrudan bir ilişkisi yok..

timeout süresine kadar inanılmaz bir RAM ihtiyacı olmaz mı ? Mesela sürekli ard arda sorgu yapılıdığını varsayalım. O zaman bu sorum daha gerçekçi olur...

Evet abi hatta bazı durumlarda koskoca bir dataset, bir datagrid yada bir image ı session da saklamak gerekebiliyor. IIS bunu arka tarafta bir cache mekanizması ile disk te saklıyor.
Hatta yavaşlıkla ilgili şunu söyleyebilirim, bazen farkında olmadan form üzerindeki kontrollerin oluşturduğu viewstate yükü session lardan daha fazla performans yakbına neden olabiliyor. (Bu arada yeri gelmişken sadece Runat Server olarak işaretlenmiş kontrollerin view state i tutulabilir. standart html kontrollerinin durumları tutulmaz.)

[mrmarman]

Bilgi için herkese teşekkürler... Çok faydalı oldu. Bunları aklımda tutarak tekrar bir inceleme yapıcam..