Newsgroup: it.comp.www.php
Titolo: [OT] Utenti padri-figli

Sto mettendo a punto un softwarino per la rivendita di un particolare
prodotto.
Questo software prevede 2 livelli - Admin e utenti.
La cosa interessante è che questo software dovrebbe essere rivendibile anche
agli utenti, che a questo punto diventano Admin loro stessi del loro
software ...
I nuovi Admin potranno rivendere il software ai loro clienti... etc etc :-)
La base di dati è centralizzata, ovvero tutta la base di dati è residente su
un solo server.
Dato che non posso e non voglio creare una tabella per ogni "livello"
gerarchico (sarebbe impossibile), sto cercando un sistema adatto.
Ovviamente dati i problemi di sicurezza, usare un ID numerico non va bene.
Pensavo a qualcosa di encode/crypt (md5 è troppo fracile) e di "encodare" il
codice utente sul codice admin... in questo modo posso riconoscere gli
utenti di un admin e l'utente stesso può diventare admin andando ad encodare
i suoi utenti sul suoi codice-pre-encoded
Beh se ci avete capito qualcosa ed avete qualche suggerimento...
cmq appena trovo una soluzione "pulita" posto qui...
J

 encodare i suoi utenti sul suoi codice-pre-encoded
non ho ben capito...
passa di mano in mano anche il codice PHP??
la struttura dei dati è complessa o si limita ad una tabella?
pensavi di utilizzare un user/password fisso oppure diversi utenti? (a 
livello di db)
passando di mano in mano, le permissions devono diminuire o rimangono le 
stesse?
che cosa malata!!!
:-)
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/free-world.html

Si è un po' incasinata la cosa.
Il codice php è strutturato seguendo la logica RMI di java, ovvero il
software chiama delle funzioni, tramite apposite classi, residenti sul
server, che tramite socket SSL passa la risposta al client (il software).
Il codice php sul client sarebbe criptato con zend-encoder, quindi non mi
preoccupo tanto di quello che sarebbe visibile (ma di certo le chiamate al
sever sql con username e pass di accesso non le metto nel codice client,
dato che sarà il server a passare le chiamate al server mysql stesso).
Ovviamente ogni cliente ed ogni admin avrà una coppia user-pass diversa e
"sceglibile a piacere" (se la username non esiste già)
La struttura dati è ancora da definire. Dato che la centralità di questo
software sta nella possibilità piramidale di far diventare un cliente un
rivenditore anch'esso, la struttura dati seguirà l'implementazione e non
viceversa. (morale, la struttura la faccio come voglio).
La questione permission non ci riguarda.
Ti faccio un esempio:
Io vendo noccioline. Ne ho in tasca 10.000
    Io vado da Pippo e gli dico "vuoi 1000 noccioline ?"
    Lui diventa mio cliente. Ha ora 1000 noccioline.
        Pippo va da Pluto e gli dice, ti vendo 300 noccioline.
        Pippo va da Topolino e gli dice, ti vendo 700 noccioline
            Pluto compra le 300 noccioline e le mangia
            Topolino compra le 700 noccioline
                Topolino va da Paperino e gli dice "ti vendo 200 noccioline"
            Topolino mangia le altre 500 noccioline
Come vedi, Pippo è mio cliente per 1000 noccioline, ma è Admin di 1000
rispetto a Pluto e Topolino (300 su Pluto, 700 su Topolino).
A questo punto, Pluto è solo cliente (perchè non rivende) mentre Topolino è
Admin di 700 noccioline. Ne vende a Paperino che non si sa che cazz ne farà
delle suo noccioline, mentre Topolino è un client per le 500 noccioline.
Quello che avevo pensato di fare, era fare l'encode di Pippo su me, l'encode
di pluto e topolino su Pippo, etc etc così da avere codici univoci di cui è
facile fare il decode (se a conoscenza del suo admin)


 dato che sarà il server a passare le chiamate al server mysql stesso).
tutto + chiaro.
beh, se sarà l'application server a connettersi al db, niente ti vieta di 
usare una semplice struttura:
id  id_padre  nome  password*  dato1  dato2  ecc..
*cryptata, al massimo
l'id può essere benissimo un autoincrementante, tanto lo legge solo il 
server!
(o mi sono perso ancora qualcosa??)
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.ic.unicamp.br/~oliva/papers/free-software/selection-html/

No è corretto dire che l'id lo legge solo il server.
Ma il server riceverà istruzioni dal client in merito alle operazioni da
fare, quindi il codice ID per il server dovrà essere messo a conoscenza del
client.
Se il client vuole togliere una particolare nocciolina a un utente, dovrà
dire
"server togli una nocciolina a ..." e ID non è l'ideale.
Inoltre l'ID non mi permette di sapere se lui è padre o figlio di qualcuno.
La struttura ad albero invece sarebbe garantita da un id cryptato sull'id
del padre
J

 ha scritto nel messaggio
news:7us89.81998$lu5.2...@twister1.libero.it...


 J
Questo perchè il server deve sapere a quale Admin togliere le noccioline :-)
J

 del padre
cioè tu vorresti, all'atto della registrazione di un utente mandare SUBITO 
il suo id al padre che dovrà ricordarselo??
così però hai bisogno anche di un repository locale...
un id numerico ti garantisce comunque l'integrità dell'albero. basta che il 
server (che alla fine è il nocciolo che si collega al db) sia programmato 
con cura.
poi non ho in mano la questione e magari ci sono problemi che non vedo.
comunque, guardare l'albero dalle foglie o dalla radice non cambia.
la differenza è che dalle foglie, riassumi una relazione 1->M con un campo, 
mentre al contrario ti viene più complesso e dovresti gestire n campi per 
gli n figli!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://php.dopoil.com

Una "idea".
Se usassi una gerarchia SET, nella quale un campo ha valori separati da
virgole
che si portano dietro la traccia dei vari parenti ?
1,3,4,2,5,6
A questo punto 3 sarebbe il terzo figlio di 1
4 Sarebbe il 4° figlio di 3, ovvero il 12 utente
2 sarebbe il 2° figlio di 4, che è il 4 figlio di 3 (e siamo già a 24)
In pratica con pochi numeri dovrei incasinare un po' la procedura di push e
pop di utenti, però andrei a velocizzare di brutto la procedura di salita e
discesa dell'albero su db.
Inoltre facendo un encode del codice, mi porto dietro una stringa "pubblica"
abbastanza complessa. Perchè 1,3,4,2,5,7 non corrisponderebbe per forza ad
un altro utente, codificandola certo non sarebbe facile da sgamare (metti
che uno voglia rubare le noccioline di un altro) :-)
Inoltre:
Questo dovrebbe assicurare il processo ricorsivo
(per sapere quante noccioline ha 5 da rivendere a 6 basta fare una query su
1,3,4,2,5 senza dover andare a fare una query prima per risalire a chi è il
padre di 6.
Inoltre cercare chi è il padre di 6 significa cercare su tutto il db
Che ne dici punka ? :)
J

il sapiente jj dice:

direi che l'idea non è malvagissima però ho 3 note:
1 - il meccanismo di gestione dell'albero si complica un pochettino
(pensa all'algoritmo di ricerca dei figli, devi cercare where pk like 
%',id,%')
2 - per cercare 1,3,4,2,5 devi comunque effettuare la ricerca.
3 - per risalire a chi è il padre di 6 (col metodo che ti ho suggerito), se 
utilizzi un indice (magari clusterizzato) sulla tabella, arrivi in un 
batter d'occhio diretamente a 6 e di conseguenza anche a suo padre.
conta che invece, indicizzando 1,3,4,2,5 ti troverai un sacco di chiavi che 
iniziano per 1,3,4* (esempio) e ti troveresti il db forzato alla lettura di 
n bytes in + (in fase di ricerca) ogni volta. se poi crypti la pk è un 
lavoro aggiuntivo!!
comunque, se ti sembra + comodo così (magari hai già tutto in testa), è 
sacrosanto il suo utilizzo!
ciao
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://groups.google.com

Giusto una nota :-)
Per le ricerche esiste la funzione mysql FIND_IN_SET che permette la ricerca
indicizzata su chiavi di tipo SET (numeri univoci separati da virgole) che è
una scheggia :-)
J

il sapiente jj dice:

sbdrgsch!!!
<macigno in testa/>
ah!!
-- 
Punkarruso
mail:punkarruso chiocchiolona despammed punto com
pubblicità progresso:
http://www.gnu.org/philosophy/free-sw.it.html