lacellula

[doGmaI]

In questi giorni mi è sorta sta strana idea...

Partendo dal presupposto che non è possibile (in genere) per un'applicazione che gira su un pc client (gioco, programma, o altro) accedere al DB hostato su un server[1] (come può essere tophost. aruba, o qualsiasi altro hosting vi venga in mente), ho cercato di immaginare una possibile soluzione.

Così mi è venuta questa idea (un po' emulando i vari programmini che permettono di spedire gli sms dai siti delle varie compagnie).

Si potrebbe realizzare una pagina php apposita che accede al DB in questione e fare in modo che l'applicazione client invece di tentare di accedere al DB direttamente chiami questa pagina a cui verrà passata la stringa SQL[2]
Questa pagina a sua volta, risiedendo sul server web, non dovrebbe avere problemi ad accedere al DB.

Questa soluzione potrebbe avere diversi vantaggi
1° nell'applicazione client non saranno mai memorizzati nome utente e password per accedere al db
2° non ci sono comandi SQL veri e proprio che viaggiano su internet
3° ogni client, anche con IP dinamino può accedere al DB di un server, permettendo di realizzare una specie di P2P, avendo a disposizione un server per qualsiasi protocollo quando in realtà il protocollo non c'è

Ma ovviamente ci sarebbero anche diversi svantaggi
1° overhead dovuto alla pagina PHP per query altrimenti molto semplici
2° complessità nella realizzazione dell'applicazione client
[e probabilmente altri che ora non mi vengono in mente]

A qualcuno è mai capitato di realizzare una cosa del genere?
Io sono in procinto di iniziare un programmino che sfrutti questa modalità, e mi chiedevo se magari c'era qualcuno che aveva già avuto esperienza in merito, giusto per avere qualche consiglio (magari qualcuno ci ha provato e sa che non è fattibile come soluzione...)

[1] ovviamente non vanno considerati server appositamente pensati per questo scopo
[2] meglio ancora, invece di usare SQL pure, crearsi una specie di metalinguaggio con comandi personalizzati che poi la pagina interpreta e traduce correttamente

[Diavolo_Rosso]

chiami questa pagina a cui verrà passata la stringa SQL[2]
Questa pagina a sua volta, risiedendo sul server web, non dovrebbe avere problemi ad accedere al DB.

mai sentito parlare di SQL Injection?  :rolleyes:

il passaggio diretto di stringhe SQL non lo si fa neanche sui siti normali e tu lo vorresti fare addirittura con applicazioni esterne?


poi ci si lamenta che i siti vanno lenti e che ci sono i server imputtanati :rolleyes:  

[doGmaI]

chiami questa pagina a cui verrà passata la stringa SQL[2]
Questa pagina a sua volta, risiedendo sul server web, non dovrebbe avere problemi ad accedere al DB.

mai sentito parlare di SQL Injection?  :rolleyes:

il passaggio diretto di stringhe SQL non lo si fa neanche sui siti normali e tu lo vorresti fare addirittura con applicazioni esterne?


poi ci si lamenta che i siti vanno lenti e che ci sono i server imputtanati :rolleyes:

[2] meglio ancora, invece di usare SQL pure, crearsi una specie di metalinguaggio con comandi personalizzati che poi la pagina interpreta e traduce correttamente

[lacellula]

Esiste già un "wrapper", anche se il termine è improprio imho.

http://sqlmanager.net/products/mysql/manager/download

Le sue funzioni di base sono molto limitate ma con un pò di pazienza mi sembrava fosse possibile sistemare il codice per essere più versatile. L'ho provato tempo addietro, solo per curiosità, e poi non ho fatto nulla con tale prodotto.

Io ho dei forti dubbi sulla reale funzionalità del metodo che tu proponi, anche per quanto riguarda gli svantaggi.

2° complessità nella realizzazione dell'applicazione client

Non concordo pienamente, anzi facendo una classe il codice potrebbe essere più pulito. Il problema, imho, sta nel fatto che un conto è far transitare dei dati dentro una LAN/SAN un conto e far passare dei dati attraverso Internet. Ti immagini fare:

Codice:

SELECT * FROM utenti LIMIT 10000;

ed aspettare che Tiscali / Alice / Tele2 lascia fluire il risultato?

[doGmaI]

Esiste già un "wrapper", anche se il termine è improprio imho.
...
ed aspettare che Tiscali / Alice / Tele2 lascia fluire il risultato?

Dell'esistenza del wrapper non ne ero a conoscenza

Per quanto riguarda la tua obiezione sulla quantità di dati concordo pienamente.
Non l'ho sottolineato io, ma ovviamente ho pensato anche a questo.
Per quanto mi riguarda, l'applicazione che andrei a realizzare, non farebbe mai una select di questo tipo.
Al più sarebbero query complesse con join, left join e simili, ma cmq per ritornare sempre un solo record (in casi estremi due), quindi dire che il traffico generato (e di conseguenza l'attesa) sarebbe cmq accettabile (chiaramente le prestazioni non saranno paragonabili a quelle di un server mysql disponibile senza "accrocchi" per l'accesso da esterno)

[lacellula]

Secondo me, allora, si potrebbe fare così. Si fa un piccolo script in PHP che accetta via $_POST o $_GET una query la quale andrebbe, ovviamente, controllata. Contestualmente si passa un numero casuale ed una eventuale chiave di sicurezza. Se la struttura del db è conosciuta, nel senso che si sanno già i campi e le tabelle si potrebbe creare, come output, un file XML contenente i record e scriverlo dentro un file chiamato come la variabile numerica. Ad esempio:

Codice:

http://www.miosito.com/sql_connector.php?rand=123456789&sec_key=ciao&query=SELECT * FROM foobar

Lo script esegue la query e crea un XML chiamato 123456789.xml, il quale verrà letto dal programma.

La prima obiezione è "Ma come faccio a dire al programma quando leggere il file XML?". Si potrebbe aspettare un tot di millisecondi, tempo più che ragionevole su un server normale, ma spesso insufficiente per server "being busy". Allora si mette alla fine dello script, quando il file è creato, un richiamo fsock_open che punta verso una porta aperta del programma stesso. Una sorta di comunicazione asincrona tra il client ed il connector.

La seconda obiezione è "Quanti files devo spendere sul webserver. Dopo 1000 queries avrò 1000 files". Anche qui si potrebbe fare in due modi: 1) Una volta che il client ha ricevuto i dati manda, tramite fsock oppure tramite GET o POST una richiesta di cancellazione del files oppure si potrebbe fare un cronjob (ovviamente su sistemi GNU/Linux) che ogni giorno cancella tutti i files.

[effe8]

Tempo fa feci delle prove con EMS SQL Manager, un programma che gira sotto windows e di cui esiste la versione gratuita.

EMS SQL Manager permette di collegarsi al proprio database attraverso un file PHP che fa da ponte di collegamento. Tale file non contiene dati sensibili. Questo genere di collegamento si chiama "tunneling".

Il termine "tunneling" si riferisce a un insieme di tecniche per cui un protocollo viene incapsulato in un protocollo dello stesso livello o di livello superiore per realizzare configurazioni particolari. Il "tunneling" viene ad esempio utilizzato per bypassare il firewall e questo si ottiene deviando il traffico di una porta (che magari e' chiusa) verso un'altra porta aperta.

Nel nostro caso il piccolo file PHP fornito con EMS SQL Manager preleva i dati mysql dalla porta 3306 e li invia attraverso la porta 80.


Questo e' il sito di EMS SQL Manager da cui si puo' prelevare gratuitamente la versione "lite" che tra le caratteristiche annovera "Access to MySQL Server through HTTP protocol", ossia il collegamento a server MySQL attraverso il protocollo HTTP (porta 80):
http://www.sqlmanager.net/en/products/mysql/manager/matrix


Questo e' un vecchio thread dove parlammo della cosa:
http://www.prozone.it/forum/index.php?showtopic=512




Buona giornata a tutti.

[doGmaI]

Tempo fa feci delle prove con EMS SQL Manager, un programma che gira sotto windows e di cui esiste la versione gratuita.
[cut]
Buona giornata a tutti.

Interessante...

Non avevo pensato a qualcosa di così completo, ma evidentemente non è nemmeno un'idea così rara

grazie F8

[effe8]

...
Non avevo pensato a qualcosa di così completo, ma evidentemente non è nemmeno un'idea così rara

grazie F8

Di nulla, e mi raccomando, si scrive "F8", ma si pronuncia "effe8".