mySQL: PHP or direct access?

[Peter Haworth]

Thanks for all the inout. I should probably have phrased my question a
little differently and asked about the pros and cons of a sever side
interface versus a direct connection rather than referencing php
specifically.  The php reference came about because of a recent post on its
use.

It appears that it comes down to a matter of good application design and
architecture more than anything else, assuming all the security issues are
addressed.

I'm probably still not understanding this completely, but how do I protect
against SQL injection attacks when using a server side interface? I can do
that very easily from within Livecode by using the parameterized variables
available with the revdbxxx calls but it seems like I would have to
implement my own version of that feature, perhaps by sending the statement
with placeholders as one message followed the values for the placeholders
in another.  I believe that's how it's done within the lc database library.


Or perhaps the structure of every individual SQL statement I need in the
application is known to the server side script and identified by an id of
some sort.  My application would then send the statement id and a list of
any required data values to the server side script instead of the SQL
statement, thus no SQL statement ever crosses the connection.

I don't think there's been an answer yet to Ralph's question about how all
this is affected by using SSL on the db connection.

On Thu, Aug 13, 2015 at 10:29 AM Mark Waddingham <mark at livecode.com> wrote:

> In general it is not advised to directly connect to databases over the
> Internet and it is considered better practice to front your db access
> through an http interface (which you could equally well implement in LC
> server running and connecting locally to the db on the server).
>
> One reason to do this is that it helps separate the db from the API used
> to access it. This reduces the 'surface area of attack' to just the
> specific HTTP API you develop for your client to connect to. It also means
> you can separate the API from the DB scheme, making it easier to evolve,
> maintain and update.
>
> Another reason (which is perhaps getting slightly less important as tech
> evolves) is that public wifi access points can restrict which ports you can
> access with some only allowing mail and web service access. As MySQL and
> other services will run on other ports to these, they would be inaccessible
> in some locations.
>
> If this is an application running on a local network which can be secured
> itself the main reason would just be structure - ie the separation of the
> backend storage implementation from the API clients vector through to
> perform their functions.
>
> Mark.
>
> Sent from my iPhone
>
> > On 13 Aug 2015, at 18:16, Peter Haworth <pete at lcsql.com> wrote:
> >
> > What are the pluses and minuses you get from using php as a middleman to
> > access a mySQL database on a server versus accessing the mySQL database
> > directly from LC?
> >
> > Web sources typically mention two main benefits: php runs on any
> platform,
> > and it's easier to create dynamic web pages.  I think the first one
> really
> > has to do with using php over any other server side language rather than
> > direct vs indirect db access.
> >
> > So assuming I have a Livecode application that does not generate dynamic
> > web pages, what other reasons might there be to use php (or not)?  And
> if I
> > do use php, how do I protect against sql injection attacks?
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>