karalamalar

Bugün valiDate metodunu çalışma arkadaşıma gösterirken, neden doğrulama başarılı olduğunda tarih nesnesini döndürmediğim sorusu aklıma geldi. Toplam 7 byte’lık ufak bir ekleme ile, doğrulama başarılı olduğunda JavaScript tarih nesnesi döndürecek şekilde metodu güncelledim. Bu sayede metottan dönen değeri hala if ifadesi içinde kullanabilirken, isterseniz if ifadesinden önce metottan dönen değeri bir değişkene atayarak, bu değişkeni if ifadesinde kullanabilir ve doğrulamayı geçerse değişkeni tarih nesnesi olarak kullanabilirsiniz. Hatta abartıp doğrulamadan dönen değeri direkt if ifadesi içinde değişkeninize atayarak da kullanabilirsiniz.

/*
 * valiDate
 * http://www.karalamalar.net/
 *
 * Copyright (c) 2009 İzzet Emre Erkan
 * Licensed under Creative Commons Attribution-Share Alike 3.0 Unported License
 * http://creativecommons.org/licenses/by-sa/3.0/
 *
 * Date: 2010-04-16 17:08:32 +0300 (Fri, 16 Apr 2010)
 * Revision: 7
 */
String.prototype.valiDate =
  function() {
    if(/^(0[1-9]|[12][0-9]|3[01])[- /.](0[1-9]|1[012])[- /.](19|20)[0-9]{2}$/.test(this)) {
      var v = this.replace(/[- /]/g,'.').split('.');
      var d=parseInt(v[0],10), m=parseInt(v[1],10), y=parseInt(v[2],10);
      var o = new Date(y, m - 1, d);
      return o.getDate() == d && o.getMonth() + 1 == m && o.getFullYear() == y ? o : false;
    }
    else
      return false;
  }

Metodun küçültülmüş halini (647 byte) buradan edinebilirsiniz.

Gün geçmiyor ki Internet Explorer yeni bir arızayla beni çıldırtmasın. Bugüne kadar hep standartları takip etmediği için çıldırtmıştı, bugün ise yeni bir standardı direkt desteklemeye başladığı için çıldırttı. IFrame içinde yer alan sayfalar Internet Explorer’da tarayıcıya çerez (cookie) gönderemeyince problemi araştırmaya başladım ve buradaki yazıya ulaştım.

Problem Internet Explorer’ın W3C tarafından gizlilik tercihleri ile ilgili oluşturulmuş Platform for Privacy Preferences Project, kısaca P3P adlı standardı desteklemesinden kaynaklanıyormuş. Tabi bu durumda buna bir problem demek doğru olur mu bu da tartışılır. Aslında iFrame içinde gösterdiğiniz sayfa farklı bir alan adından çağrılıyorsa, asıl alan adındaki çerezlerin etkilenmemesi/kötüye kullanılamaması için geliştirilmiş bir önlem. Firefox’ta varsayılan olarak bu ayar kapalı geliyor. İsteğe bağlı olarak kendiniz açabiliyorsunuz. Internet Explorer ise varsayılan olarak bu ayarı açık olarak kullanıyor. Lafı fazla uzatmaya gerek yok aslında. P3P hakkında detaylı bilgiye buradan ulaşabilirsiniz. Ben size sorunu nasıl çözebileceğinizden bahsedeyim;

İsterseniz çeşitli online araçlarla kendi P3P kodunuzu üretebilirsiniz(IBM P3P Policy Editor). Uğraşmak istemeyenler iFrame içinde çalışacak olan ve çerez gönderecek olan her sayfanın başlık bilgilerinde P3P için özel bir bilgi göndermeniz gerekiyor. Çeşitli platformlar için örnekleri ekliyorum. Burada yer almayan fakat sizin kullandığınız bir platform varsa, örnek olarak ekleyebilirseniz sevinirim.

PHP:

header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');

ASP.NET (C#);

HttpContext.Current.Response.AddHeader("p3p","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\"");

Django:

response = render_to_response('mytemplate.html')
response["P3P"] = 'CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"'

JSP:

response.addHeader("P3P","CP=\"IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\"")

Rails:

response.headers['P3P'] = 'CP="NON DSP COR CURa IVAa IVDa CONa OUR NOR STA"'

Geçen gün uygulamalarımızın çalıştığı sunucunun olay kayıtlarını incelerken ASP.NET’in sürekli olarak bu hata ile karşılaştığını gördüm. Bunun neticesinde web siteleri kimi zaman cevap veremez duruma geliyordu. Internette biraz araştırma yaptığımda genelde geliştiricilerin Visual Studio’da çalışırken bu hatayla karşılaştıklarını gördüm. Bir süre çözüm aradıktan sonra bu yazıyı bulduk(Engin ile birlikte). Benim gibi bu problemle karşılaşmış ve çözüm yolu arayışındaki başka bir geliştiricinin bulduğu çözümü ben de sizlerle paylaşayım dedim.

web.config dosyanızda system.web elemanına aşağıdaki kod öbeğini ekleyerek sorundan kurtulabilirsiniz.

shadowCopyBinAssemblies özelliği şu şekilde tanımlanmış: Bir Boolean(Evet/Hayır) değeri ile uygulamanın Bin klasöründe yer alan bileşenlerinin, gölge kopyalarının (shadow copy) uygulamanın ASP.NET geçici dosyalar klasörüne kopyalanıp kopyalanmayacağını belirtir.

Umarım işinize yarar.