Most secure Flash > MySQL connection

Question

Currently the major means of connecting Flash AS2/AS3 to a MySQL database are:

1. Flash > PHP > MySQL -- "secure code" in PHP Scripts
2. Flash Asql or Assql > MySQL -- "secure code" in MySQL Stored Procedures

The second approach is newer, but directly connects to a MySQL DB using binary sockets and ByteArrays.

In which case would the "secure code" be less accessible and therefore more secure?

I'm assuming stored procedures cannot be accessed via FTP so that might be harder to break into?

Answer 1

Stored procedures can only be accessed by someone with the correct database credentials so they will be secure assuming no one cracks your Data Base password. You know it might actually be that the PHP code is more secure as you can hold the Data Base password on the server instead of in the host app.

I suppose you can always decompile flash and try to locate the password in the host app because with asql the password will be stored in the host app, instead of on the server hidden behind PHP

Answer 2

I'm not sure asql would work for users behind the proxy, so I wouldn't use it for website. Approach with PHP in the middle seems to be better and you can (and should) model api for your application that is different from your DB structure.

Answer 3

It appears that both assql and binary sockets are synchronous links that use a socket connection to the database. Which might be great for an AIR application, but for a browser app might be highly problematical. Is this for sure what you want? Your question about access through stored procedures gives me the idea you aren't too sure about this stuff.

In fact, using PHP properly will likely be easier for building a solid abstraction and security indirection barrier between your app (and its host) and the database.

---

EDIT:

Web clients and servers use the http protocol to communicate. This is called a "stateless" and "connectionless" (which is only kinda true) protocol because the connection between the two only lasts as long as it takes for the client to request everything and the server to send back everything. The obvious benefit is that the server only knows about each client for a very brief period of time.

A socket (in the sense these two protocols use one) is a permanently established connection between the client and server that persists until one end or the other closes it (connection-based); and both sides know the state of the connection (open or closed). So they tie up a lot of host resources per client for a long time, and things get wacky when the connection breaks. Big difference, and it can't be run through the ports supporting web pages - another port needs to be provided (sometimes two) on the host and the client to support the socket.