[vz-dev] public kanaele ?

[Steffen Vogel]

Am Freitag, den 24.06.2011, 23:49 +0200 schrieb Justin Otherguy:
> Hi,
> 
> Am 24.06.2011 um 17:41 schrieb Steffen Vogel:
> 
> >> ABER, zum nachdenken:  damit kann dann jeder, der eine private UUID kennt, diese dann
> >> auch public setzen ?!?  oder die "resolution" usw. aendern ?!  
> ...und Daten senden...
Also, wir brauchen schnell ne Lösung! ;)

> > Ich hatte mal an eine Art Token System gedacht. Oder doch ein
> > konventionelles Passwort, dass zum Bearbeiten & Löschen angegeben werden
> > muss?
> > 
> > Wir könnten so ein Passwort auch rein optional machen:
> > 
> > - Geheimer Kanal (public=0) braucht nicht unbedingt ein Passwort.
> > - Öffentlicher Kanal (public=1) kann ein Passwort bekommen um ihn vor
> > dem Löschen/Bearbeiten zu schützen?
> Passwort gefällt mir nicht; sobald wir Passwörter haben, brauchen wir Mailadressen für den Reset...
Stimmt. Lassen wir es dann besser.

> Und bei dem Ansatz wäre das Passwort nur für öffentliche Kanäle verzichtbar...
> 
> Hab mir mal sowas ausgedacht:
> - ein public-Kanal ist ein ganz normaler Kanal mit einer einzigen Besonderheit: er hat einen "public"-Eintrag
> - der bewirkt, dass die middleware keine schreibenden Zugriffe auf die Daten dieser uuid zulässt
> - zu jedem public-Kanal gibt es einen "secret twin" mit einer separaten uuid
> - unter dieser uuid stehen keine Daten
> - diese nichtöffentliche uuid verweist auf die zugehörige uuid des public-Kanals
> 
> -> Zugriff auf die public-uuid: middleware erlaubt nur lesenden Zugriff
> -> Zugriff auf die private-uuid: middleware setzt die Zugriffe auf die zugehörige public-uuid um
> 
> Haken an der Sache:
> - bei jedem Zugriff erfolgt zuerst ein Check, ob die uuid public ist :-/
> 
> Was meint Ihr?
:) Das find ich gut. Kommt auch dem nahe, was ich mir unter dem Token
Ansatz ausgedacht habe. Ich würde es noch etwas weiter abwandeln:

Ein Kanal muss mindestens eine UUID (Token) haben. Er kann aber auch
mehrere haben:

1. Secret UUID mit vollen Rechten
2. Eine Public UUID mit Leserechten
3. weitere Secret UUID für weiteren "User/Controller"

Falls jetzt mal eine Secret UUID ausversehen veröffentlich wird, könnten
wir diese einfach "zurückziehen" und eine neue Secret UUID erstellen.

Von außen betrachtet eigentlich genau das, was Justin sich ausgedacht
hat. Nur in der Implementierung etwas anders umgesetzt.

Ein Kanal wäre dann nicht mehr eindeutig durch EINE UUID zuordbar.

Bin mir nicht sicher wie das aus Datenbanktechnischer Sicht so
vertretbar ist. Realisierbar wäre es auf jeden Fall.

gruß Steffen
-- 
Steffen Vogel
Robensstraße 69
52070 Aachen

Handy: +49 176 96978528
Mail: info at steffenvogel.de
Web: http://www.steffenvogel.de
Jabber: stv0g at jabber.ccc.de
ICQ: 236033
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://volkszaehler.org/pipermail/volkszaehler-dev/attachments/20110625/2b68cca4/attachment.pgp>