Sistema di registrazione e login da inserire sui siti

[soulcanada]

Ciao a tutti,
girando per il forum ho visto che molti utenti chiedono aiuto per la realizzazione di un sistema di login e relativa registrazione ma incontrano difficoltà (di solito i problemi sono sempre uguali) quindi vorrei un vostro parere su un'ideuzza che mi è venuta:
se realizzassi un sistema di login e relativa registrazione da utilizzare embedded sui siti?

Mi spiego meglio: ho in mente un sistema centralizzato che permetta la gestione utenti (quindi login, registrazione, recupero password ecc...) e che possa poi essere incluso nei vari siti che ne avranno bisogno.

Logicamente, dato che altervista supporta le SSL, tutti i dati verranno "passati" tramite questo protocollo.

Ora, vorrei un vostro parere riguardo questa idea (ed eventuali suggerimenti).

Ciao ciao e grazie dell'attenzione.

[karl94]

Esiste già, esistono alche altri servizi di identificazione ben più diffusi (basti pensare a FacebookConnect), affinché la tua idea abbia successo dovresti dunque introdurre una novità attualmente non presente negli attuali sistemi.

[soulcanada]

Esiste già, esistono alche altri servizi di identificazione ben più diffusi (basti pensare a FacebookConnect), affinché la tua idea abbia successo dovresti dunque introdurre una novità attualmente non presente negli attuali sistemi.

Diciamo che esistono mille mila servizi come quello che propongo solamente che, a differenza degli altri, il mio sarebbe solo dedicato ai siti di altervista e il più semplice possibile da inserire e personalizzare.

L'idea di fondo è di permettere ai webmaster di altervista di non sviluppare un sistema di gestione utenti ma di utilizzarne uno già pronto.

Non tutti hanno le conoscenze (tanti sono alle prime armi) quindi il servizio dovrebbe essere semplicissimo da integrare.

[lc12net]

Io sono d'accordo con Soulcanada. Parlo per esperienza personale, andare sul pannello di controllo e poter trovare l'opzione crea area riservata in cui mi installi il pacchetto sul mio spazio web sarebbe una grande comodità rispetto a dover costruire i vari codici in php.

[alemoppo]

Diciamo che esistono mille mila servizi come quello che propongo solamente che, a differenza degli altri, il mio sarebbe solo dedicato ai siti di altervista e il più semplice possibile da inserire e personalizzare.

Quello che sto tentando io... però ancora sono all'inizio... E non so fin dove arriverò... (anche perché richiede tempo, e io in questo periodo ne ho davvero poco, per via degli esami)...

Ciao!

[soulcanada]

La mia idea è leggermente differente:

immagino un web service che offra le funzionalità basilari di storage dei dati e le principali funzionalità (tipo la registrazione di un nuovo utente, il login, il recupero password ecc...).

L'interrogazione avviene poi tramite una classe che offra i metodi principali e deve essere utilizzata direttamente dal webmaster.

A livello di utente finale, il tutto deve apparire trasparente ovvero l'utente finale non sà che le credenziali sono memorizzate in una macchina diversa.

Tramite determinate api offerte dal servizio ed implementate nella classe che ho detto precedentemente, il webmaster può agire sui dati dei suoi utenti per offrire le funzionalità che vuole.

I dati poi vengono trasmessi tramite SSL e salvati crittografati in modo da mantenere un alto livello di sicurezza.

[alemoppo]

immagino un web service che offra le funzionalità basilari di storage dei dati e le principali funzionalità (tipo la registrazione di un nuovo utente, il login, il recupero password ecc...).

Quello è quello che sto facendo (anzi, dovrebbe già essere così).

L'interrogazione avviene poi tramite una classe che offra i metodi principali e deve essere utilizzata direttamente dal webmaster.

Io invece l'ho pensata come se un webmaster non sapesse usare i metodi (e le classi).
Anche perché, se vedi, lo script che ho fatto non è oop, sia perché l'avevo iniziato in modo non molto serio, sia perché volevo mantenere la compatibilità con php4 (non si possono usare private, ...); ma il webmaster ha a disposizione soltanto $_SESSION['utente'].
Puoi indicare i "metodi principali"? Forse li farò sotto forma di funzioni, ma penso sia uguale...

A livello di utente finale, il tutto deve apparire trasparente ovvero l'utente finale non sà che le credenziali sono memorizzate in una macchina diversa.

Non lo sa comunque. E perché deve essere memorizzato in una macchina diversa? Anche perché i dati vanno a sommarsi a quelli dei vari file contenuti nel proprio spazio...

Comunque, avevo pensato anche ad una implementazione sqlite, in modo di non avere il limite delle query, e di poter far il backup molto più facilmente (è un file).

Comunque, in questi giorni ho 3 esami, e praticamente ancora non ho iniziato a studiare. Quindi non ho molto tempo, ma vedrò di farlo più avanti.

Ciao!

Io ho un'idea:

Creare un dominio login.altervista.org per esempio, installarci un DB e creare il form del login da poter integrare nel sito tramite JS, iFrame o HTML.

Fare l'action del form al sito login.av.org e settare un cookie valido non nel sottodominio login, ma su av.org in modo che possa essere letto da qualsiasi sito, oppure nel sito referer.

Una volta avuto un cookie, si potrebbe fare una specie di API in vari formati per poter salvare i dati e leggerli in qualsiasi portale.

Ho reso l'idea o no?

[alemoppo]

Ho reso l'idea o no?

Sì, non è male... Ma bisogna aver l'approvazione (o meglio, la partecipazione) di altervista.
Comunque, in questo modo i dati sarebbero "infiniti", nel senso che non è possibile conteggiare lo spazio database nel proprio spazio (a meno di mettere dei limiti di numero iscritti)... Quindi bisognerebbe mettere in gioco AC....

Comunque, per chi ha AC, può essere un bel servizio.

Ciao!

Che approvazione serve? Il dominio è un sito registrato normalmente, si utilizzano i propri servizi e si hosta un progetto come qualsiasi, con la differenza che le API funzionano solo su AV.

Poi se prende e funziona, non credo che Giunluca non lo installerà nel pannelli di controllo, in questo modo si potrebbe usare il sistema AC e donare tramite pannello.

[soulcanada]

Quello è quello che sto facendo (anzi, dovrebbe già essere così).

No non è un web service, il tuo è uno script da scaricare ed integrare nel sito mentre quello che vorrei io è proprio bypassare tutto questo passaggio (certo poi un minimo di integrazione serve ma tutta la configurazione, controlli, db e simili non saranno a carico del webmaster).

Puoi indicare i "metodi principali"? Forse li farò sotto forma di funzioni, ma penso sia uguale...

Purtroppo no perchè ho solo un'idea in testa e non ho ancora definito nulla.

E perché deve essere memorizzato in una macchina diversa? Anche perché i dati vanno a sommarsi a quelli dei vari file contenuti nel proprio spazio...

Perchè non è detto che i vari siti siano sulla stessa macchina

Comunque, avevo pensato anche ad una implementazione sqlite, in modo di non avere il limite delle query, e di poter far il backup molto più facilmente (è un file).

Sai che questa è un'ottima idea... me gusta assai...

Io ho un'idea:

Creare un dominio login.altervista.org per esempio, installarci un DB e creare il form del login da poter integrare nel sito tramite JS, iFrame o HTML.

Fare l'action del form al sito login.av.org e settare un cookie valido non nel sottodominio login, ma su av.org in modo che possa essere letto da qualsiasi sito, oppure nel sito referer.

Una volta avuto un cookie, si potrebbe fare una specie di API in vari formati per poter salvare i dati e leggerli in qualsiasi portale.

Ho reso l'idea o no?

Io farei i cookie validi solamente per il dominio di terzo (o quarto) livello solamente per questioni di sicurezza, vorrei che ogni sito potesse leggere solamente il cookie a lui assegnato.

Sì, non è male... Ma bisogna aver l'approvazione (o meglio, la partecipazione) di altervista.
Comunque, in questo modo i dati sarebbero "infiniti", nel senso che non è possibile conteggiare lo spazio database nel proprio spazio (a meno di mettere dei limiti di numero iscritti)... Quindi bisognerebbe mettere in gioco AC....

Comunque, per chi ha AC, può essere un bel servizio.

Ciao!

Potremmo trovare un modo di garantire il servizio e gli AC disponibili offrendo un servizio "limitato" e gratuito mentre uno "premium" con una piccola donazione (sempre se possibile e se il regolamento lo permette e solamente per pagare le spese di mantenimento non per lucrarci).

Che ne dite?

[alemoppo]

Io farei i cookie validi solamente per il dominio di terzo (o quarto) livello solamente per questioni di sicurezza, vorrei che ogni sito potesse leggere solamente il cookie a lui assegnato.

Temo però che per far questo, occorra settare il cookie nel dominio .altervista.org. Quindi questo è possibile leggerlo da tutti i sottodomini (in questo caso, tutti i sottodomini possono leggere i cookie di tutti).
Da quel che so, non è possibile (correggetemi se sbaglio) creare un cookie da login.altervista.org solo per nomesito.altervista.org.

Comunque:
(es login):
Si fa questo form che punta a login.altervista.org (o equivalente), quindi questo controlla se la pass/nick sono corretti, e procede con il login (ad esempio, scrive in un cookie chiamato "nomesito" una chiave univoca {una sorta di sess_id}).
A questo punto, sul sito nomesito.altervista.org si ha a disposizione soltanto il cookie: se ad esempio si vuol fare un sistema commenti soltanto per gli utenti registrati, come fa nomesito.altervista.org a capire che il cookie non è stato modificato?

Come fa a capire il nick? Direte: salviamo nel cookie anche il nick.. ma poi come si verifica che quello è veramente il suo nick, e non è stato modificato?

Cioè: il problema è la verifica dell'autenticità dei dati nei cookie visto che nomesito.altervista.org non ha alcuna possibilità di dialogare con il database posto in login.altervista.org.

Per queste autenticità si potrebbe fare un dialogo "nascosto" via ajax, ma capite da soli che ... . Tra l'altro, ricordo che su "nomesito.altervista.org" abbiamo a disposizione soltanto javascript. Sarebbe fattibile con l'uso degli iframe, ma personalmente li trovo disgustosi.

Se avete altre idee...

Ciao!

EDIT:

Ecco, trovato. Tempo fa avevano già tentato di fare una cosa simile. Però a quei tempi non riuscivo a capir nulla .

[soulcanada]

Temo però che per far questo, occorra settare il cookie nel dominio .altervista.org. Quindi questo è possibile leggerlo da tutti i sottodomini (in questo caso, tutti i sottodomini possono leggere i cookie di tutti).
Da quel che so, non è possibile (correggetemi se sbaglio) creare un cookie da login.altervista.org solo per nomesito.altervista.org.

Hai ragione, non è possibile far creare un cookie valido per nomesito.altervista.org da login.altervista.org ma possiamo fare in modo che sia proprio nomesito.altervista.org a creare il proprio cookie tramite delle regole e delle chiavi pubbliche fornite da login.altervista.org

Comunque:
(es login):
Si fa questo form che punta a login.altervista.org (o equivalente), quindi questo controlla se la pass/nick sono corretti, e procede con il login (ad esempio, scrive in un cookie chiamato "nomesito" una chiave univoca {una sorta di sess_id}).
A questo punto, sul sito nomesito.altervista.org si ha a disposizione soltanto il cookie: se ad esempio si vuol fare un sistema commenti soltanto per gli utenti registrati, come fa nomesito.altervista.org a capire che il cookie non è stato modificato?

Come fa a capire il nick? Direte: salviamo nel cookie anche il nick.. ma poi come si verifica che quello è veramente il suo nick, e non è stato modificato?

Cioè: il problema è la verifica dell'autenticità dei dati nei cookie visto che nomesito.altervista.org non ha alcuna possibilità di dialogare con il database posto in login.altervista.org.

Non può dialogare in senso stretto con il db ma, tramite le api fornite dal servizio, avrà la possibilità di chiedere se l'utente ha un'identità oppure no.

Per queste autenticità si potrebbe fare un dialogo "nascosto" via ajax, ma capite da soli che ... . Tra l'altro, ricordo che su "nomesito.altervista.org" abbiamo a disposizione soltanto javascript. Sarebbe fattibile con l'uso degli iframe, ma personalmente li trovo disgustosi.

Ajax logicamente non permette richieste extra dominio per questioni di sicurezza e, come dici tu, un sistema per bypassare questa limitazione è usare degli iframe oppure utilizzare una connessione server2server (questo però comporta un innalzamento dei tempi di risposta del sito richiedente).

Ecco, trovato. Tempo fa avevano già tentato di fare una cosa simile. Però a quei tempi non riuscivo a capir nulla .

Il sito non funziona...

Quello che si sta cercando di fare è la stessa cosa che usa Google con i suoi servizi esterni, addirittura alcuni non stanno su terzo dominio, ma hanno un dominio a se: vedi youtube.

Se il servizio dovrà essere dedicato, si salva anche il dominio, altrimenti come open_av, non c'è bisogno dato che basta UN cookie per vedere se è loggato o no ed usare le API per vedere se è loggato o meno.

Il cookie sarà criptato e al suo interno verrà salvato l'identificativo univoco (id numerico possibilmente) e un md5 con salt che sarà la sessione per verificarne l'autenticità ed il login.

Il form login del sito punterà SEMPRE a login.av.org e verrà rendirizzato al sito dal quale è arrivato solo se proveniente da av (basta fare un parsing dell'url) e si setterà un cookie su av.org, ma con il nome dell'account di AV, in modo da poterlo estrarre in base al dominio (sempre che non si faccia open_av).

Che poi, essendo su un terzo livello di AV, se non ricordo male, da login.av.org si dovrebbe poter salvare un cookie su pincopallo.av.org avendo lo stesso dominio di base, ma vanno fatti dei test per sicurezza, non ne sono sicuro.

[alemoppo]

Scusate, ma ancora non ho capito (sì: forse son scemo!)

Quello che fa google, penso sia un pò differente: è vero che google, gmail, youtube (e forse altri) usano lo stesso account, ma tra loro son sicuro che vanno a leggere nello stesso database. Noi invece dobbiamo fare una cosa senza php (altrimenti, se occorre far caricare del php agli utenti, allora tanto vale fare una cosa tipo quella che avevo iniziato).
Cioè, google, youtube sicuramente (ovvio, direi ) hanno anche una parte server-side. Quindi lato server si può fare quello che uno vuole. Il problema da quel che ho capito, è che si vuole fare un sistema tipo "le pubblicità di av": uno inserisce il codice html (o js, ma comunque lato client) e ha il suo sistema login che si interfaccia con login.altervista.org (o equivalente).

Parlate anche di API, ma è proprio questo che stiamo cercando di fare, giusto?

Non può dialogare in senso stretto con il db ma, tramite le api fornite dal servizio, avrà la possibilità di chiedere se l'utente ha un'identità oppure no.

Appunto, è necessaria una parte server-side.

oppure utilizzare una connessione server2server (questo però comporta un innalzamento dei tempi di risposta del sito richiedente).

...e si ricade nel php

Ciao!

Inserire una parte di codice che sia PHP, JS o cosa, che cambia? Sempre devi modificare il file.

Il nostro sistema è lo stesso: gli utenti sono su login.av.org, da li parte la sessione per poter usare il widget negli altri siti, ma sempre su login gestisci il tutto, PHP o JS che sia, dato che alla fine dipende dal genere di API che fai.

[alemoppo]

...ma allora tanto vale usare il database del proprio sito, no?
Ad esempio, in quello che avevo iniziato, non è necessario configurare nulla (a parte creare la tabella, visitando la pagina "install"). Ogniuno utilizzerebbe il proprio db {per non dire che si potrebbe anche usare sqlite, se il sito non è enorme (a questo punto, sarebbe ancora più facile per l'utente, perché per la creazione del database e le varie tabelle se ne accorgerebbe da solo lo script, quindi potrebbe crearle da solo) }, quindi proprio spazio, proprio numero di query... Cioè: non capisco più il senso di questa cosa... E perché dovrebbe essere meglio di quello che avevo iniziato? {ok, sarà anche scritto male , però comunque si tratta solo di rifarlo meglio. Non capisco a questo punto perché appoggiarsi ad un altro sottodominio}.
Inizialmente, io avevo capito così:

No non è un web service, il tuo è uno script da scaricare ed integrare nel sito mentre quello che vorrei io è proprio bypassare tutto questo passaggio (certo poi un minimo di integrazione serve ma tutta la configurazione, controlli, db e simili non saranno a carico del webmaster).

Anche se "tutta la configurazione, controlli, db e simili", anche in quello che ho fatto non sono a carico del webmaster.

Ciao!

EDIT: capisco di essere insistente, ma davvero non riesco a capire come intendere di gestire il tutto.

[karl94]

È diverso, questo sistema vuole essere come OpenID, permettendo una registrazione una tantum riutilizzabile in tutti i siti che aderiscono al sistema di identificazione. Un simile sistema introduce anche diversi vantaggi: in una sola registrazione si inseriscono tutti i dati del profilo, come avatar, nome, indirizzo, mail e così via. Ci sarebbe però l'inconveniente lato sicurezza di avere accesso a differenti servizi con le medesime credenziali (si potrebbe ovviare permettendo l'uso di credenziali secondarie a seconda del servizio).

Comunque un implementazione lato client, benché possibile (è sufficiente sfruttare appositi header HTTP per permettere richieste cross-domain), è fortemente sconsigliabile poiché costringe l'utente ad avere supporto per Javascript.

Dimenticavo, inoltre è possibile impostare un cookie su un dominio differente da quello attuale, anche superiore (non però su quelli di primo livello). Però sarebbe meglio che il cookie rimanga solo sul dominio che gestisce il servizio.

Quindi la mia idea è sensata o no?

[karl94]

Continuo a non capire perché ad un webmaster convenga scegliere questo sistema anziché altri ben più grossi, con più utenti, e altrettanto semplici da inserire. A mio parere affinché il progetto possa prendere piede è necessario offrire qualcosa di nuovo e di unico.

[soulcanada]

Ciao Altervistiani,
ieri stavo navigando tra le varie discussioni del forum ed ho notato che uno dei temi caldi risulta sempre essere quello riguardante il login e la registrazione degli utenti e mi è tornata in mente questa discussione.

Mi sono messo a rileggere le varie risposte/proposte e mi ha molto divertito vedere tutta questa partecipazione quindi vorrei "riaprire" la discussione aggiungendo alcuni particolari che non avevo riportato nel mio primo post e che, ne sono sicuro, potranno rendere più chiara a voi l'idea iniziale del progetto.

Il punto principale dell'intero sistema è la possibilità che un webmaster possa inserire nel proprio sito un'area protetta da password in modo semplice e veloce senza implementare script PHP (o comunque meno codice possibile) nel proprio codice ma utilizzando una piattaforma costruita ad hoc che offra tutte le principali funzionalità richieste (login, logout, registrazione, ecc...) mantenendo comunque una buona possibilità di customizzazione; per come la vedo io mi piacerebbe che le pagine che offrono le funzionalità possano essere richiamate attraverso una semplice chiamata ajax alla piattaforma che restituirà tutto il codice HTML/CSS/JAVASCRIPT necessario.

Ipotizziamo che un utente voglia accedere alla pagina di login del sito site.av.org il quale utilizza la piattaforma di login offerta dal sito login.av.org:

1. L'utente richiede la pagina login.php del sito site.av.org
2. La pagina login.php contiene un codice javascript che effettua (magari tramite jsonp) la richiesta di un modulo di login per il sito site.av.org al sito login.av.org
3. login.av.org risponde con del codice html che contiene il form di login
4. La pagina login.php inserisce quel codice html direttamente nel proprio mostrando il form all'utente
5. L'utente compila il form e preme il pulsante di sottomissione del form
6. Il codice javascript della pagina login.php fa una chiamata a login.av.org, passando le informazioni, che valida i dati inseriti dall'utente
7. login.av.org risponde positivamente inviando alla pagina login.php la url di redirect ed una serie di token di autenticazione/autorizzazione
8. Il codice javascript della pagina login.php legge i token settando dei cookie e redirige l'utente alla url di redirect del sito site.av.org

A grandi linee (ma molto grandi) questo dovrebbe essere il funzionamento di un ipotetico login.

i token restituiti saranno:

• Token di autenticazione: serve per identificare la sessione e l'utente
• Token di autorizzazione: serve alla successiva chiamata alla piattaforma

Mentre il token di autenticazione rimane per tutta la durata della sessione quello di autorizzazione cambia ogni volta che viene richiesta una pagina/funzionalità alla piattaforma (è un sistema simile a quello che ho utilizzato per un sistema di pagamento).

Spero di essere stato più chiaro dell'ultima volta e spero anche che l'idea vi possa piacere e vogliate prendervi parte.

P.S: ho "riesumato" la discussione invece di farne una nuova e mi auguro di non aver infranto il regolamento e, nel malaugurato caso lo avessi fatto, spostate pure il post in una nuova discussione e perdonate il mio errore.

[wfs]

Ri-scrivo in questa discussione dopo sei mesi. Vedo che ancora nessuno ha finito di sviluppare login.altervista.org, perciò ci provo io. Ma non capisco questa idea di non usare il PHP. Io farò il servizio CON il PHP.
EDIT:


PS Il login sarà accessibile da login.wfs.altervista.org.

[soulcanada]

Ma non capisco questa idea di non usare il PHP. Io farò il servizio CON il PHP.

Che cosa intendi con "farò il servizio con il php"?

Come lo implementerai a livello utente (cioè come lo inserirà/userà l'utente finale)?

[wfs]

Lo inserirà tramite FTP e metterà il form di login con un semplice

<?php include 'login_sys/login.php'; ?>

e un

<?php include 'login_sys/registered.php'; ?>

all' inizio di una pagina per indicare che è visibile solo agli utenti registrati.
Però ancora non so se riuscirò a finire il progetto poichè è decisamente complicato.
EDIT:
Creati file login.php (che contiene il form di login. E' *.php perchè include cfg.php che contiene alcuni dati inseriti dal creatore del sito), validate.php (Che valida i dati di login.php), install.php (che crea il database).

[karinafolkmusic]

Eccone uno bello e pronto Cool Syst

[wfs]

@karinafolkmusic: non hai capito... nè io, nè soulcanada vogliamo un form di login per i nostri siti... bensì vogliamo crearne uno nuovo da scaricare e da far inserire ad altri utenti AlterVista nei propri siti! Hai letto il resto della discussione?