Özel mesajlaşma sistemi ile kullanıcı başına veritabanı senaryosu

Kullanıcıların diğer kullanıcılara mesaj gönderebildiği bir sistemin nasıl kurulacağını merak ediyordum. Elbette herkesin sadece gelen kutusuna erişebilmesi gerekiyor, bu yüzden bunun için kullanıcı veritabanı altyapısına ihtiyacımız var. http://guide.couchdb.org/draft/notifications.html örneğinden sonra, kullanıcıların mesajları sadece alıcının veri tabanına koyabilirdi. Basit ve etkili.

Ancak, kullanıcıların alıcı veritabanı adını bilmesine izin vermek istemezsek? Alıcının veritabanını, ileti belgesinin to alanına bakılarak çözecek bir sistem istiyorsak (bu, veritabanı adıyla tamamen ilgisiz olan kullanıcı adı olabilir):

{
    "to": "john.kowalski",
    "from": "jake.podolski",
    "subject": "hi",
    "message": "..."
}

Ek katman için mükemmel bir görev gibi görünüyor, ama sonra eğlenceli ve soruya değmez, bu yüzden çoğaltma ile çözmeye çalışacağız:

  1. Kullanıcı, mesaj veritabanını ana veritabanına koyar
  2. Çoğaltma görevi (her kullanıcı için bir görevimiz olurdu), bu dokümanı, _changes beslemesini - alanına filtreleyen bir filtre kullanarak getirir. "John.kowalski" adı filtre işlevi için parametre olarak iletilecekti.
  3. Doküman, alıcı veritabanında sona eriyor.

However, this creates a problem, because main database would have to be visible to all users! So...what if we would be able to add user->main replication task as well, so that the messages would be picked up from user database transferred to main database and then placed in recipients database (oh lord, it's getting complicated, we may already waste our time by trying to solve it this way, but let's try).

  1. Kullanıcı, iletiyi kendi veritabanına koyar
  2. Çoğaltma görevi bu dokümanı getirir, ancak buradaki filtre kullanıcının sahip olduğu ve bu nedenle güvenilemediği için herhangi bir türde filtre işlevini kullanamaz.
  3. Ana veritabanı dokümanı doğrular - kaynak veritabanıyla ilişkilendirilen from alanının olup olmadığını kontrol eder.
  4. Önceki yaklaşımda kullanılan çoğaltma görevi, belgeyi alıcıya aktarır.

Burada üçüncü adımda sorun var (bu adım olmadan, kullanıcılar 'den alanından sahte bilgileri doldurarak diğer kullanıcıları taklit eden mesajlar gönderebilecekler) - doğrulama işlevlerine ek verileri nasıl aktarabiliriz? , bildiğim kadarıyla tek parametreler:

  • eski doktor
  • yeni doküman
  • kullanıcı bağlamı (günlüğe kaydedilen kullanıcı adı, roller, db hangi belgeye yazılıyor)
  • güvenlik nesnesi?

1.1.0 sürümünde başlatılan çoğaltıcı veritabanı işlevselliği üzerinde loooking yaparak, user_ctx içeriğini çoğaltma görevine geçirebiliriz. Bu nesnenin gerçek kullanıcı bilgisinin aksine özel veriler içermesi mümkün mü? Bu, CouchDB'nin veritabanı erişimini standart olarak nasıl etkiler?

Bu mümkün olsaydı, çoğaltma görevi sadece alıcı adı user_ctx altında parametre olarak doldurulur, ardından doğrulama işlevi bu değeri from alanıyla karşılaştırmak için kullanırdı. Kullanıcının kendisinden başka biri olarak mesaj göndermesi için bir yol olmaz.

5
Bir kayıt için, burada sadece çoğaltmayı kötüye kullanabileceğimin farkındayım ve yönetici olarak çalışan bazı çalışan görevleri (böylece tüm veritabanlarını okuyabilir) belgeleri daha sağlam ve basit bir şekilde taşıyabilir.
katma yazar Bartosz, kaynak

3 cevap

Burada büyük bir varsayım yaptın:

Ancak, bu bir sorun oluşturur, çünkü ana veritabanı   tüm kullanıcılar tarafından görülebilir!

Tüm kullanıcılara açık bir ana veri tabanına sahip olmaktan kaçınan alternatif bir çözüm var. Her kullanıcının mesaj belgelerini doğrudan ana veritabanına koymasını sağlamak yerine, kullanıcıların kendi veritabanlarına mesaj belgeleri kaydetmesini ve iletileri ana veritabanına aktarmak için filtrelenmiş çoğaltmayı kurmasını sağlayabilirsiniz. Ana veritabanı kısıtlanabilir, böylece uygulamanızın normal kullanıcıları buna erişemez. Kullanıcı veritabanları ve ana veritabanı arasındaki çoğaltma bir yönetici tarafından başlatılmalıdır, ancak çoğaltma görevleri CouchDB'nin geçerli sürümlerinde kalıcı olduğundan bu yalnızca her kullanıcı için bir kez yapılmalıdır.

2
katma

Bu soru şu soruya benzer: CouchDB kullanıcı oluşturma .

Bu soruda olduğu gibi, gelen kutusu veritabanım yamamın bunu yapacağı konusunda iyimserim hepsi çok daha güzel.

1
katma
Evet, gerçekten harika bir yama!
katma yazar Bartosz, kaynak

Kanepeyi, kullanıcının bir veritabanında normal belgeleri okuma ve yazma haklarına sahip olmasını sağlayabilir, ancak _design belgelerini değiştiremezsiniz. Bu şekilde, kullanıcının sitesinde dağıtılmadığı sürece, kullanıcının veritabanında doğrulama yapmaya güvenebilirsiniz, ancak verileri yine de veritabanınıza kopyalamanız gerekir. Sanırım işçinin bu görevle yapılabileceğine dair ifadenizi kabul edebilirim :). Aslında, birleştirme/kümelemenin de harici python betikleriyle yapıldığını düşünürken, "Couch Way" olacağına inanıyorum.

1
katma
Çalışırdım, ancak kullanıcıların tasarım dokümanlarını değiştirmelerine izin vermek istiyorum (couchapp'ler aracılığıyla özelleştirmeler), böylece veritabanlarının yöneticileri olmalılar.
katma yazar Bartosz, kaynak