La tua domanda è molto confusa. Immagino che l'inglese non sia la tua prima lingua e quello che stai chiedendo veramente è "dovrebbe essere esposto un DBMS su Internet?"

he does not want the database password in the code

Questo è solo l'inizio dei tuoi problemi.

Ci sono cose che puoi fare per rendere il problema meno grave di quello che stai attualmente proponendo, ma lasciano comunque un lotto a desiderare.

Utilizza le credenziali fornite dall'utente per l'autenticazione nel DBMS

vale a dire. la password del database è la password dell'utente. Ciò limita l'uso del database agli utenti noti (anziché renderlo disponibile a chiunque su Internet) e rimuove la necessità di incorporare la password del database nel client. Ma non risolve nessuno degli altri problemi.

limita l'accesso degli account solo alle stored procedure

Fatto correttamente, ciò impedirebbe a un utente malintenzionato di leggere elementi dal database a cui non dovrebbero avere accesso - ad es. dovrebbero solo essere in grado di vedere i loro ordini e non gli ordini di altre persone. Consente inoltre di implementare la logica aziendale sul lato server (non è possibile affidare la logica implementata sul client). Non si dovrebbero mai memorizzare dati che non sono stati controllati per la conformità. Ciò offre anche alcune possibilità di gestire l'esperienza dell'utente in maniera più efficace quando le cose non procedono lungo il percorso felice. Tuttavia è davvero difficile implementare la logica dell'applicazione in SQL procedurale.

limita l'accesso a indirizzi IP specifici

Dove solo gli indirizzi IP noti accederanno a un servizio, questa è una buona pratica: riduce il rumore, ma non è infallibile. E la tua menzione di un'app IOS (presumo che tu ti riferisca a iOS, il sistema operativo del dispositivo mobile Apple, non IOS, che è il sistema operativo del dispositivo di rete di Cisco) suggerisce che non sarai in grado di determinare in anticipo l'indirizzo del cliente.

... ma questi non sono abbastanza protezione !!!

I DBMS semplicemente non sono progettati per essere esposti in un ambiente potenzialmente ostile. E SQL, utilizzando lo stesso canale per i dati e il controllo, è particolarmente suscettibile agli abusi. Nessuno è stato in grado di risolvere questi problemi su un DBMS - e in effetti, nessuno sta provando più come la soluzione è quella di implementare un livello di controllo adeguato, serveride, in cima al DBMS.

    

PENSO CHE STA FACENDO SENSO DI PROVARE QUESTO !!

L'IT è davvero confuso ma l'uso della soluzione ajax soddisferà le tue esigenze!

1. scrivi i codici javascript e salva come file .js ! nel documento ... scrivi il metodo "GET" / "POST" con password e nome utente che collegherà l'app al server o al file .php ... che manterrà la connessione actuall al server! ad esempio: funzione "get obtainData (datasource) {if (window.XMLHttpRequestObject) {XMLHttpRequestObject.open (" GET ", datasource, userName, password);} ...}"
2. e quindi utilizzare la funzione eval () per consentire la valutazione del javascript recuperato o php durante onreadystatechange, readystate == 4 & & stato == 200; ....

questa hoever verrà salvata come documento javascript esterno che verrà incluso utilizzando "<" script src="doc.js". . . ">" che risulterà che quando il documento viene visualizzato, la password contenente il codice sorgente sarà vista come .js e non quella attiva! PENSO CHE LA PASSWORD E ALTRE INFORMAZIONI NON VERRANNO PREGIUDIZI ALLE MALPRESSIONI IN QUANTO SARÀ ESEGUITO NELL'AJAX DI .JS!