Ana içeriğe geç

Rentiva v5.2.3 / Pro v5.2.3 — WordPress'in aslında hiç bakmadığı bir tablo ve yanlış şeyleri sayan bir gizlilik metni

· 4 dakikalık okuma
MaxHandMade
MaxHandMade
Maintainer

WordPress.org başvurusuna giden yolda bir yama sürümü daha. İlginç olan kısmı düzelttiğimiz hata değil, o hatayı dürüst anlatıp anlatmadığımızı kontrol ederken bulduklarımız.

Hiçbir zaman uygulanamayacak olan tablo güncellemesi​

WordPress'in dbDelta() diye bir fonksiyonu var: ona bir CREATE TABLE ifadesi verirsiniz, o da elinizdeki tabloyla arasındaki farkı bulur ve son sürümden beri eklediğiniz sütunları, içindeki veriye dokunmadan ekler. Bir eklentinin kendi şemasını güvenle geliştirmesinin yolu budur.

Bu fonksiyon ifadeyi çalıştırmaz, ayrıştırır. Tablonun adını bulma yöntemi de şudur: CREATE TABLE kelimelerinden sonraki ilk şeyi alır.

Bizim arka plan iş tablomuz CREATE TABLE IF NOT EXISTS ile oluşturuluyordu. Yani dbDelta(), o tablo var olduğundan beri, adı IF olan bir tabloyu izliyordu.

Tablonun kendisi sorunsuzdu — ham ifadeyi veritabanı hep doğru çalıştırdı. Kaybolan veri yok, bugün sitenizde yanlış olan bir şey de yok. Ama dbDelta() ayrıştırdığı ada karşı DESCRIBE koşar, DESCRIBE IF başarısız olur ve tarif edemediği bir tabloyu tümüyle atlar. İleride o tabloya ekleyeceğimiz her sütun sessizce yok sayılacaktı: hata yok, uyarı yok, dbDelta() başarı bildirirken hiçbir şey yapmıyor.

Bunu akıl yürüterek değil ölçerek doğruladık. Şemaya bir sütun ekleyip göçü yeniden koşturduk — düzeltmeden önce sütun oluşmadı, düzeltmeden sonra oluştu.

Aynı kusur ücretli eklentideki iki CREATE TABLE ifadesinde daha vardı. Biri — rapor arka plan iş tablosu — etkinleştirmede oluşturuluyor ve sorunu gerçekten yaşıyordu. Diğeri şu an hiçbir yerden başlatılmayan bir izleme alt sistemine ait; iki kod yolu aynı okunsun diye onu da düzelttik, ama bunu açıkça söylemeyi, changelog'un hiç çalışmamış bir şeyi onardığımızı ima etmesine tercih ederiz.

Yanlış olduğu için baştan yazılan gizlilik metni​

readme'nin Gizlilik bölümü, site sahibinin kendi gizlilik politikasına kopyaladığı kısımdır. Bizimki, her rezervasyon kaydının ziyaretçinin IP adresini ve tarayıcı bilgisini sakladığını söylüyordu.

Neredeyse tam tersi çıktı.

Rezervasyona IP yazan kod, eklentide hiçbir şeyin gönderim yapmadığı bir ucun arkasında duruyor. Gerçek rezervasyon akışı — form, sepet, WooCommerce ödeme sayfası — hiç IP kaydetmiyor. Yani beyan ettiğimiz tek depo, pratikte neredeyse hiç var olmayanıydı.

Buna karşılık var olan üçü hiç anılmamıştı:

  • İletişim formu. Her gönderim; gönderenin adı, e-postası, telefonu, firması, mesajın kendisi, eklediği dosyanın bağlantısı ve geldiği IP ile tarayıcı bilgisiyle saklanıyor. Bu kayıtların saklama süresi ayarı yok ve hiçbir şey onları silmiyor. Eklenen dosya sıradan yükleme klasörüne gidiyor, bağlantıyı bilen herkesçe erişilebilir, ve mesajı silseniz bile orada kalıyor.
  • Değerlendirme formu. Yorumlar sıradan WordPress yorumu olarak saklanıyor, dolayısıyla IP ve tarayıcı bilgisini WordPress'in kendisi kaydediyor — her yorumda yaptığı gibi. Misafir yorumlarına Araçlar → Kişisel Veriyi Sil üzerinden ulaşılabiliyor, çünkü orası yorumları e-posta adresiyle eşliyor. Giriş yapmış bir müşterinin bıraktığı yorum ise kullanıcı kimliğine bağlı, üstünde e-posta olmadan saklanıyor; o araçlar onu bulamaz, Yorumlar ekranından silmeniz gerekir.
  • E-posta günlüğü. Alıcı ve konunun yanında, her mesajın hangi rezervasyon bilgilerinden üretildiğini de tutuyor: müşteri adı, iletişim bilgileri, kiralama tarihleri. Derlenmiş mesaj gövdesini tutmuyor. Kendi saklama ayarı var, varsayılan 30 gün.

Doğru anlattığımız etkinlik günlüğü ise girdi başına IP, tarayıcı bilgisi ve kullanıcı kimliğini, yine varsayılan 30 günlük ayarlanabilir bir süreyle tutuyor.

Bu sürümde eklentinin ne sakladığı değişmedi. Değişen şey, onun tarifinin artık doğru olması. Eski metnimizden yazılmış bir gizlilik politikanız varsa, yeni bölüme karşı bir kez okumaya değer.

Bunu nasıl bulduk — asıl yazılmaya değer kısım​

Bunların hiçbiri düzeltmeden çıkmadı. Düzeltmeyi bağımsız bir modelin önüne koyup kendi tarifimizi çürütmesini istememizden çıktı — beş tur boyunca. Her tur, bir önceki turu düzeltmek için az önce yazdığımız metinde bir şey buldu: koruma listesini silme listesi sanmak; bir testin normalize edilmiş anahtar adlarını gerçek adlar sanmak; kodda yüz altmış bir tane varken on demek.

Hepsinin ortak deseni aynıydı: bir şeyin ne anlama geldiğini okumak yerine varsaymak. Bunu açıkça yazmaya değer, çünkü kendinden emin, iyi yazılmış ama yanlış olan belge tam da böyle üretilir — ve gizlilik metni, bunun gerçek zarar verdiği belge türüdür.

Aynı turlar, 5.2.1'den beri release ZIP'lerimizin içinde yolculuk eden bir çalışma dosyasını da ortaya çıkardı. Artık derleme, arşivin kökünde ne bulunabileceğinin beyaz listesini tutuyor ve başka bir şey varsa üretmeyi reddediyor; çünkü elimizdeki hariç tutma listesi ancak birinin aklına gelmiş dosyaları yakalayabilirdi.

Güncelleme​

Yapmanız gereken bir şey yok. Düzeltilen tablo için bekleyen bir sütun olmadığından güncellemede sitenizde bir şey değişmez; düzeltme, bir sonraki şema değişikliğinin gerçekten uygulanmasını sağlar. Pro 5.2.3 birlikte yayınlanıyor ve Lite 5.2.3 gerektiriyor.