sono tanti sistemi per mettere in piedi qualcosa del genere ti riferisci ad
un insieme di tecnologie o esistono delle piattaforme apposite per
sviluppare queste cose?
Intendo dire entrambe le cose:
un insieme di tecnologie (e di scelte) che devono essere messe in campo,
e per realizzarle ci sono poi delle piattaforme apposite.
Le quali pero' dipendono dalle scelte tecnologiche che si e' fatto,
dalla strada che si e' deciso di intraprendere, e da dove queste
applicazioni andranno a funzionare.
Altra mia curiosità: per utilizzare PhpPgAdmin in sicurezza c'è bisogno di
implementare qualcosa di particolare o potrei pensare di utilizzarlo in
parte per il mio scopo?
Su questo punto sono oggettivamente in difficolta' a risponderti.
phppgadmin e' un tools per amministrare il dbms,
e dal mio punto di vista non centra niente con il problema di dare a
degli utenti esterni la possibilita di inserire dei valori nel
database ?
la lgoci e' comunque quella che dicevo.
Una web-application che tramite un application server mette in
colloquio il client (l'utente),
con il dbms.
In merito al fatto di esporre su Internet tale strumento, sta alle
scelte dei singoli.
Intanto non si espone il dbms, ma un tools di gestione che "vive" su
un'altra macchina (l'application server della precedente email).
E quindi non ti costringe ad esporre il dbms.
Per cui se ti bucano questa macchina al massimo non riesci piu' a
amministrare remotamente il tuo dbms, ma non rischi i dati.
Da qui a dire che questa scelta sia giusta pero' ce ne corre.
Il rischio qui non e' diretto ( il dbms non e' esposto su internet),
ma e' indiretto, perche' transita su Internet la password per accedere
al dbms come amministratore.
E su internet e' esposto il portone (phppgadmin) su cui inserire la
chiave (la password)
Pero' su questo filone il discorso porta lontano, perche' si passa
subito alle citazioni sulla criptazione delle passwords.
Per cui diciamo che
se e' sconveniente esporre il dbms.
Esporre il sistema di gestione, porta comunque dei rischi, ma minori.
Il che non vuol dire che sia del tutto sicuro.
Questo tipo di scelta, in certi contesti, qualcuno e' portato a
ritenere che siano dei rischi ragionevoli. Ovviamente dipende dal
contesto.
Ciao,
Andrea.
2008/9/5 <marcobrizz77@alice.it>:
Grazie Andrea per i consigli,
non nascondo che sono un po' confuso su quello che mi hai detto. Ho capito
che è bene rinunciare a l'utilizzo di openoffice. Quando dici che che ci
sono tanti sistemi per mettere in piedi qualcosa del genere ti riferisci ad
un insieme di tecnologie o esistono delle piattaforme apposite per
sviluppare queste cose?
Altra mia curiosità: per utilizzare PhpPgAdmin in sicurezza c'è bisogno di
implementare qualcosa di particolare o potrei pensare di utilizzarlo in
parte per il mio scopo?
Grazie
Marco B.
________________________________
Da: gfoss-bounces@faunalia.com per conto di Andrea Peri
Inviato: mer 03/09/2008 12.22
A: gfoss@faunalia.it
Oggetto: Re: [Gfoss] R: postgresql e openoffice
Ciao,
nel secondo reply inviato ti ho risposto a questa ipotesi.
Secondo me questo tipo di problematica e' troppo complessa per poter
fornire un suggerimento che sia pertinente.
Sistemi per mettere in piedi qualcosa del genere ce ne sono tanti e se
ne puo' inventare sempre di nuovi.
Alla base di certe scelte ci sono considerazioni sul tipo di sviluppo,
sul tempo a disposizione, sulle conoscenze di cui si puo' disporre,
sul tipo di architettura su cui si va a insistere (da noi per esempio
il php non sarebbe usabile). Sul tipo di gestione che si deve fare poi
del sistema.
Un elemento poi abbastanza critico e' stabilire se "ogni utente scrive
su record distinti o possono collidere sui medesimi records".
E cosi' via...
Per cui mi rimane difficile darti una indicazione precisa e utile.
in llinea di massima
i clienti colloquiano via server web.
per cui metti su una web-application direttamente su server web in php
ad esempio
e tramite un application server (tomcat) se vuoi usare il java.
la web-application colloquia con il dbms, e implementa la cosidetta
"business logic", ovvero prende i records li elabora e prepara delle
pagine che invia al browser del cliente (al comue)
L'utente riempe le pagine con le sue informazioni e le ritorna alla
web-application
La quale girera' poi il contenuto al dbms per la memorizzazione.
Un punto saliente e che poiche' le connessioni cosifatte sono dette
"session-less".
Tra una e l'altra perdi il contatto con il dbms e quindi non riesci a
gestire la persistenza del collegamento,
ai fini di impedire che due utenti si cancellio 8 ocomunque
interferiscnao a vicenda) nei dati del dbms.
Per gestire questo si ricorre a dei meccanismi di cui il piu'
conosciuto e' il "cookies" con il quale
viene marcata una sessione di collegamento di un utente.
La web-application pensera' cosi (ma devi metterci il codice per
farlo) a smistare le richieste di scrittura sul DB evitando le
collisioni.
Saluti,
Ciao Andrea,
tu non hai capito la mia mail (scusate se mi sono spiegato male ma anche io
sono un po' confuso su come realizzare questo sistema) >e io non ho capito
molto bene la tua risposta (causa la mia poca esperienza in materia).
Credo che quello che vorrei fare è più simile a "esporre il dbms postgres
direttamente su Internet e farci accedere i vari comuni tramite >un
applicativo scritto su OpenOffice dai loro computer remoti".
In locale quando io utilizzo openoffice posso collegarlo a postgresql e
usare openoffice per riempire le tabelle di postgresql. Quindi mi >chiedevo
se una cosa simile posso farla usando un database in remoto e usando più
file .odb (uno per utente=per ciascun comune); >una cosa simile ha senso o
ci sono sistemi migliori?
Grazie per l'aiuto
Marco B.
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Alice Messenger 
chatti anche con gli amici di Windows Live Messenger e
tutti i telefonini TIM!
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~