Burdaki sorun; sadece platform adlarına göre arama yapabiliyorum. Oysa hem platform adlarına göre, hem e-posta ve kullanıcı adlarına göre arama yapabilmek istiyorum.
O yüzden doğru veri yapısını ve bu veri yapısı ile en doğru şekilde kullanılabilecek arama ve sıralama algoritmasını seçmem gerekiyor.
Şimdi bu verileri bir sözlükte (dict) tutmanın kullanım kolaylığı açısından mantıklı olacağını düşündüm:
Trie, ortak prefixlere sahip bir suru verinin oldugu kelime listesi gibi yapilar icin uygun. Bahsettiginiz problemde hic bir seyi kolaylastiracagini dusunemiyorum.
Sozlukler (dict) belirli bir key’e denk gelen datayi cok hizli bir sekilde bulabilirler, bunu “tam olarak girilen data” aramasi icin indis olarak kullanabilirsiniz.
Ornekte gosterdiginiz data bir array; artan sayisal key’leriniz var. Ha, soyle bir avantaji var, 1’i sildiginizde 2 ve sonrasinin indisi (key’i) degismiyor. Yani (johnDoe → 1, DoeJohn → 2) gibi index’ler tutmaniza olanak sagliyor.
Veritabani yeterince kucuk olacagindan hafiza icinde arama yapabilirsiniz. Yani for loop’u kullanarak.
Siralama icin de son kullanilma zamani iyi bir anahtar olabilir.
Kesinlikle katılıyorum, sadece deneme amacıyla yapmıştım.
Aslında sadece örnek olması amacıyla paylaşmıştım bu data’yı. Daha verileri nasıl bir şekilde tutacağımı bulamadım. Sonuçta sözlük (dict) kendi içinde bile çok farklı şekillerde kullanılabiliyor.
Evet bu senaryo için öyle, peki daha komplex projeler için ne önerebilirsiniz?
Veritabanlarinin text veya fulltext indexleme mekanizmalarina bakabilirsiniz. Veya dogrudan bir veritabani kullanabilirsiniz.
Datanin en dogal/yalin sekli array, fakat bahsettigim gibi indisleyebilmek veya aradan entry silebilmek icin bir ID kolonuna ihtiyaciniz olabilir, bu sefer de en dogru hali sizin yaptiginiz gibi bir (ID → data_struct) map’i (dict) oluyor.
Yukaridaki cevapta ima ettigim gibi, zaten veritabanlari veriyi tek bir sekilde tutmaz. “Indeks” dedigimiz sey verinin baska bir sekilde kesilmis ve bukulmus hali (orn: { "instagram": 2, "facebook": 1 }) ve butun indeksler ana veriden olusturulabilecegi icin hepsi tanim geregi fazlalik.
Kisacasi veriyi amaciniz icin kesip bukup baska bir formata cevireceginize gore, bir versiyonunu hafizada nasil tutacaginiz uzerine cok dusunmenize gerek yok.
Diskte nasil tutacaginiz daha onemli olabilir mesela.
Platform adlarına göre arama yapmak ile diğer veriler arasında arama yapmak arasındaki fark ne?
Ben fark görmedim.
Burda plaform verisine nasıl erişip arıyorsanız, username ve mail gibi elemanlara da aynı şekilde erişip arama yapabilirsiniz.
Ha şöyle bir durum var. Şifre verilerini bu şekilde tutan bir güvenlik yazzılımı kadar güvenilmez bir şey olamaz. Dünyanın en tehlikeli veri saklama şekli.
Mutlaka bir veri tabanı programı kullanın, verileri hangi elemanına göre arayacaksanız, ona göre indeksletin ve mutlaka hash benzeri şekilde kaydedin.
Dümdüz kaydederek kesinlikle şifre saklanmamalı.
Ağaç yapısının konu ile hiç bir alakası yok. Neden ihtiyaç duyacağınızı düşündünüz anlamadım.
Ağaç yapısı kullandım çünkü bir yerden başlamam gerekiyordu. Örnek olarak denedim ihtiyacımı karşılamadığını anlayıp bıraktım.
Ağaç yapısına sadece plaform verisini ekleyebildim, diğer verileri de birbirleriyle bağlantılı şekilde ekleyemedim. Zaten MatchContains ve CaseInsensitive özelliği de ekleyemedim.
Şöyle bişi yaptım:
def searchData(self):
search_text = self.search_edit.text().strip().lower()
if not search_text:
return
result = []
for key, value in self.data.items():
for field, content in value.items():
if isinstance(content, str) and search_text in content.lower():
result.append((key, value))
break
Evet kesinlikle haklısınız, zaten öyle bi amacım yoktu, sadece örnek olarak yapıyorum. Bu aşamada amacım güvenlik ve gizlilik değil, daha arama yapamıyorum ; onlara daha zaman var.
Ama madem konusu açıldı: aklıma takılan bir şeyi sormak istiyorum;
Veritabanı kullanmak yerine verileri bir json dosyasına yazıp şifrelesem ve kullanacağım zaman decrypt etsem olmaz mı?
Yerel veri tabanı yapıp bıraktım. Kimseye uygulamayı göndermedim henüz tamamlanmadı. Kimsenin benim uygulamama güvenip şifresini riske atma riskini göze alamadım.
Çocuklarım için trt çocuk yayın akışını çeken bir mobil uygulama yaptım şimdilik. Televizyonda sevdikleri film ne zaman başlayacak onu görsünler diye kolay yoldan. Hobi olarak uğraşıyorum kendim ve cevremdekiler için. @aib nin önerdiği keypass mantığı şimdilik en güvenli yerel db yöntemi olarak geldi bana. Dokümantasyonu biraz karışık geldi, boş vakitte içine dalmam ve uğraşmam lazım. Okulun ilk haftaları biraz yoğun benim açımdan.
Olabilir tabi ki, neden olmasın. Bunu çeşitli sebeplerden isteyebilirsiniz.
Konu burada ikiye ayrılır. İndeksleme ve arama işlemlerini bir veritabanına devretmek arama, sıralama algoritmaları ile uğraşmamak içindir. Tutarlılık okunabilirlik ve taşınabilirik açısından da fayda sağlar.
Ama ben sıralama algoritmaları ve arama algoritmaları için egzersiz yapıyorum derseniz. Bu parola ve diğer kayıtları, xml , binary, text istediğiniz dosya türünde kaydedip saklayabilirsiniz.
Konu güvenlik olmadığına göre ve sadece arama algoritmaları ve kayıtlar için egzersiz yapmak istiyorsanız okunaklı olması açısında metin tabanlı bir dosya sistemi seçip Bağlı liste veri dosyaları, indeksleme yöntemleri konusunda manuel çalışabilirsiniz. Belki kod yazma vaktim olursa örnekleyecek kodlar da yazabilirim.
Bence bu kadar abartmaya gerek yok, cunku guvenlik acisindan bakildiginda zaten cok fazla opsiyon yok: Sifreli/sifresiz, veya muhtelif faktorlere gore sifrelenmis/sifrelenmemis.
Hazir program veya kutuphane kullaniyorsak guvenlik denetimlerinden gecmis sifre depolama aletlerinden bir tanesi kullanilabilir. Ustelik veritabani gibi “ev yapimi” cozumlerde cikacagi neredeyse garanti olan guvenlik aciklarindan da korunma saglanmis olur.
Sosyal medya şifreleri tutan örnek görünce ve çoğu sızıntının paralo sayfalarını sızdırılmasıyla elde edildiğini düşünürsek abartmak demeyelim temel güvenlik seviyesi diyelim. Yani parola ve kullanıcı adlarını açık saklamak yapılmaması gereken temel yaklaşım olmalı. Ha abartmamak şu aşamada söylenebilir, bir güvenli şifre yazılımı değil basit bir denemeymiş. Bu durumda algoritma çalışmak için tabi ki gerekli denemez.
Bu konuda aynı fikirdeyim. Güvenlik yönünden test edilmiş en azından taşma hatasıyla bile aşılabilen bir kod yerine denemiş kütüphaneler kullanılması taraftarıyım.
Sonuç itibariyle, giriş gelişme sonuç biraz farklı çıkıyor sorularda.
Buradan bakınca parola yöneticisi profesyonel bir yazılım üzerinde çalışıyor gibi görünüyor gelişme ve sonuç bölümünde;
Yani iş egzersiz seviyesine inmiş.
Bu durumda tabi ki parola ve diğer verileri gizlemek gerekmeyebilir.
Daha basit veri yapıları ve deneme algoritmaları seviyesine inince konu çok da detaylandırmaya gerek kalmadı.
Ha şahsen ben bir kütüphane kullanmayacaksam yapacağım şey birden çok dosya kullanmak olurdu.
Birinci dosya verileri tutar, diğer dosyalar da istediği sıralama ve aramaya göre, ana dosyanın kayıt indekslerini tutuardı. Veri tabanı programları da buna benzer bir yaklaşım izliyor.
“Hyperbole” kelimesinin karsiligini ariyordum. Abartmak degil tam olarak, evet. “Dunyanin en tehlikeli veri saklama sekli” deyince, sanki bir skala varmis gibi duruyor. Oysa cok basit, neredeyse tek bir parametre var: Sifreleme. Dediginiz gibi, gerektigi ve gerekmedigi durumlar var.
Neyse ki, bu karar tasarimin belki en buyuk parcasi olmasina ragmen, gelistirmenin cok ufak bir parcasi. Dogru yontemler ogrenildikten sonra cok ufak degisikliklerden soz ediyoruz…
Tum veri hafizaya sigdigi surece, birden fazla dosya kullanma gibi optimizasyonlara gitmeye gerek yok. Bu asamada indeks kullanma gibi algoritmik degisiklikler, veya programin kullanim amacinin/seklinin belirlenip ona gore cizilen hedeflere giden degisiklikler cok daha onemli.
Haklısınız kullanılabilir ve daha mantıklı da olabilir ama benim amacım bir şeyler yapıp deneyim kazanmak.
Hem bu tür platform/kütüphaneler her ne kadar ihtiyaçlarımızı karşılasa da, bazen kişinin farklı yaklaşımlarına çözüm üretemiyor olabilir. Hal böyle olunca kişi kendi ihtiyaçlarına uygun şeyler yapmayı deneyebiliyor. Benim durumum da böyle.
Şimdilik öyle bir yaklaşımım var.
AES kullanmayı düşünüyordum, KeePass’in de bu algoritmayı kullandığını gördüm.
Burada iki başlık öne çıkıyor;
İlk başlık: AES implementasyonlarınından hangisini seçeceğim ve hangisine güveneceğim?
İkinci başlık ise AESi hangi modda kullanmalıyım? KeePassCipher Block Chaining (CBC) kullanıyor ama benim aklımda Galois/counter (GCM) vardı.
Acik kaynakli ve tercihen ucuncu partiler tarafindan denetlenmis olan bir tanesini.
Yazdigim sira suradakiyle ayni olunca dogrudan link vereyim dedim.
Ikisi de iyidir.
“Bu soruyu soruyorsaniz yapacaginiz sistem guvensiz olacaktir muhtemelen” de var tabi. Ben de soruyorum/bilmiyorum. NaCl gibi cryptografi uzmani olmayan insanlar icin tasarlanmis bir kutuphaneye (veya dogrudan uzmanlara) birakmak en iyisi olabilir. Donup dolasip su yaziya denk geliyorum.
The problem is there are a lot of pitfalls regarding cryptography and it is extremely easy to build a system that looks secure for the layman but is trivial to break for a knowledgeable attacker.
; onlara daha zaman var.
JSON’a yazip sifreleyebilirsiniz. Sifreleyip JSON’a da yazabilirsiniz.
