Is it a good thing to convert all MySQL Database to JSON when viewing websites.
I am able to create a PHP script to Javascript that will create variables for each tables in the database with JSON structure in each with information. I found this to be a lot quicker to code information on page from MySQL. But I just wondering if that will cause slow downs or problems when more and more information are added to the database.
Hmm so all your server side code does is read your database and covert it directly to JSON? Here's what I would be worried about
Security Risks -- Everything is being sent over the wire now, the full structure and contents of your database can be acquired. You may become subject to some cross-site scripting or other attack. An attacker may acquire confidential information in your database. If this interface is bidirectional attackers may be able to modify or corrupt your database more easily then if you had a better interface.
Poorly defined interface -- Design the interface between the server and client so that you're working at the right level of abstraction. By simply transcibing the database over to javascript, your interface may not be accurately describing whats happening in appropriate vocabulary. You want names for actions reflecting what the javascript is actually trying to do. For example, instead of having a simple Json "AddUser" command, you now have a long string of Json queries for editing tables. If I was the javascript coder, I'd prefer a simple "AddUser" over having to figure out all the tables that needed to be modified.
Changes aren't isolated -- Every time your database changes a little bit you need to update the javascript code to deal with minor updates/renames. If the database structure changes significantly, then instead of having an isolated change with server side code, now all your javascript also has to change.
If it was me, I would think about the correct abstraction to provide the javascript code from the server code, this would both help to manage security and readability in a maintainable way.
Ok, be aware for security risks, but you can always sincronize the data from your javascript with the global session of server side using ajax. Must have a way to validade the data inserted by the client side. Because to depend only on the information stored in the browser for process some information, its almost dangerous.
Related
I'm new to Android programming and I'm trying to create an app which needs a persistent remote database. Now, coming from Java and local databases, I've always connected application and database directly, without an intermediary.
I'm not seeing the point of this workaround, can someone please make this clear? I've tried searching on Google, but it seems everybody assumes this as a principles (or maybe I need to look for better keywords).
The most important argument that I can think of right now is SECURITY/QUERY VERIFICATION.
You most likely want to use an online database (perhaps MySQL) because you want to store shared information between ALL users of your application in it. The major difference between a local and an online database is that many many users have access to it - both writing and reading access.
So imagine you have your android application and now want to save some user generated data from it in your online database. Assume there is no PHP intermediary: The app directly sends the finished MySQL request to the database.
But what happens if someone looks into the source code of your app or uses any other way to manipulate that request? Let's say he changes a query from
SELECT * FROM user WHERE ID=9434896
to
SELECT * FROM user
Exactly - he gets all information from your user data table, including sensitive data such as passwords or E-Mail Addresses.
What evaluates these queries and prevents them from happening?
Your app surely doesn't, because the user can easily manipulate/change the app.Your MySQL database doesn't check them either, because it always assumes that the query is what the developer actually wanted. As long as the syntax is correct, it will execute it.
And that's what you need the PHP intermediary for:
You send values to a PHP file (e.g. check_login.php receives the values 267432(userid) and hie8774h7dch37 (password)), the PHP file then checks if these values are actually a userid (e.g. "Are they numeric values only?") and then builds a MySQL query out of it.
This way the user has no way to manipulate the query as he wishes. (He can still send wrong values; but depending on the situation it is also possible for a PHP script to check if the values are legit or not)
Perhaps this will give you some context. I built a game on Android and iPhone, and I wanted high scores stored in a remote database.
Security is the main reason you would do this. You should always do data validation on the server side, not client side. By doing it this way, my php script can validate input before making changes on the database. In addition, it is not safe to store database credentials in your apk file. This opens up a range of security vulnerabilities. Safer to keep this on the server side.
Secondly, by utilizing a single PHP script, I only need to debug/manage code that validates data and interacts with my database in 1 place... the php file. This saves me plenty of time rather than updating all of the queries and validating criteria in both the iPhone and Android instances.
I am sure there are other benefits to this approach, but these are the reasons why I do it this way.
It's an abstraction layer. You don't want to code your app to MySQL and then discover your backend is moving to MS-SQL. Also, you control how you present information to the user. If they have access, they can read everything. If you have an abstraction layer, then they can only get information by going through the proper channels.
I am creating an app for my clients to add to their webpages. however, I am hosting the database that stores the info for this app. All I want to do is do all the queries on my server and somehow pass the $var to their server.
so what I was thinking was to have my PHP page with all the MYSQL credentials store on my server and give them a code that calls that page and outputs the stuff, something like
require_once('192.163.163.163/config.php');
But I bet this is the least secure way to do this. I don't want to give anyone access to the central database and I am handling all the requests. Do you guys have any suggestions that I can pull the data off my db and pass it to their server in a $var without opening any doors?
If you can't afford to give away your DB credentials or other internal details of your system but you need the clients to be able to read data from you, then the only really secure way to do set your system up as an API that the clients can call.
Don't try to combine the two systems into a single app; it will open up holes that cannot be closed.
To create an API is fairly simple in principle. Just create a suite of normal PHP programs that accept a set of pre-defined arguments return the data in a pre-defined format that can be easily processed by the calling program -- eg maybe a JSON structure.
The clients would then simply call your system via an HTTP call. They'd never need to see your code; the wouldn't need to be hosted on the same server, and they wouldn't even need to be writing their system in the same language as yours.
There's a lot more to it than that -- it is, of course, perfectly easy to write an insecure API as well, and you'll want to read up on how to write a good API to avoid that sort of thing -- but that's your starting point. I hope it helps.
Would it be safe to use a MySQL database to record positions of players on the screen?
Then everyone second, Flash retrieves the new position data in the database and sets the players' positions of the map to the new positions?
I'm not sure how slow this would be.
I know PHP.
I know SQL.
I am not very experienced in ActionScript, but I can do basic things like set positions of objects.
I do not know how to retrieve information from a database via Flash.
I do not know how to make Flash send out queries.
Do you think you could give me a bit of help?
It would be safe to use MySQL.
But, I strongly wouldn't recommend using PHP + MySQL as a game server though, or your server will tend to lock up from the influx of requests. The HTTP protocol was not designed for this.
It might take a bit of time, but I would learn an easy programming language (especially something like Java or C#) to create a basic server. Then you can store their user information within RAM, instead of constantly accessing the database repeatedly. But, you could also have it where the server updates a database every n amount of minutes, in case the server is shutdown and needs to be started back up with the same data.
Look up 'Flash Remoting' for flash<->server communications. An open-source server-side handler for that is AMFPHP. Flash would send out AMF messages, AMFPHP translates that back into normal PHP data structures, and then you'd have the PHP code handle interfacing to the database.
you would have php be a controller between your db and flash. So flash would send/receive info from php and php would query db.
Yeah, MySQL is pretty secure, as long as you strip all tags, mysql injection etc from the string. And it should be pretty instant.
However, hundreds of MySQL requests every second will be a lot of bandwidth, although I can't think of any alternatives.
This is a beginner question...
In a website, what type of data should or should not be included inside the session? I understand that I should not include any info that needs to remain secure. I'm more interested in programming best practice. For example, it is possible to include into the session some data which would otherwise be sent from page to page as dependency injection. Wouldn't that correspond to creating a global variable?
Generally speaking, what kind of data has or hasn't its place inside a session table?
Thanks,
JDelage
The minimum amount of information needed to maintain needed state information between requests.
You should treat your session as a write-once, read many storage. But one which is rather volatile - e.g. the state of your underlying application data should be consistent (or recoverable) if all the sessions suddenly disappeared.
There are some exceptions to this (normally the shopping basket would be stored in the session - but you might want to perform stock adjustments to 'reserve' items prior to checkout). Here items may be added/edited/changed multiple times - so its not really write-once - but by pre-reserving stock items you are maintaining the recoverabiltiy of the database - but an implication of this is that you should reverse the stock adjustments when the session expires in the absence of completion.
If you start trying to store information about the data relating to individual page turns, you're quickly going to get into problems when the user starts clicking on the forward/back buttons or opens a new window.
In general you can put anything you like in a session. It's bad practice to put information in a session that has to be present to make your page run without (technical) errors.
I suggest to minimize the amount of data in your session as much as possible.
stuff you can save in the session so that you dont have to make another database query for info that isn't going to change. like their username, address, phone number, account balance, security permissions on your site, etc.
(This is perhaps more than you're looking for, but might make for good additional information to add to the good answers already posted.)
Since you mention best practices, you may want to look into some projects/technologies which can be used to take the idea of session state a bit further. One common pitfall with horizontally scaling web applications across multiple servers is maintaining session state between them. (User A logs in to Server A which stores the user's session, but on the next request hits Server B which doesn't know about User A's session, etc.)
One of the things I always end up saying to myself and to colleagues is that session by itself isn't really the best place to store data, even if that data is highly transient in nature. A web server is a request/response system, not a data store. It's highly tuned to the former, but not always so great for the latter.
Thus, there are ways to externalize your application's session data (or any stateful data, which should really be kept to a design minimum in the RESTful stateless nature of the web) from your web server and to another system. Memcached is a very common tool for this. There are also drop-in session replacements (or configurable session options for various frameworks/environments) which store session in a database like SQL or MySQL.
One idea I've been toying with lately is to store session data (well, any transient data where it's OK to lose it in a catastrophe) in a NoSQL database. CouchDB and MongoDB are my current top choices for this, but there's no shortage of other options. CouchDB has excellent horizontal scaling, MongoDB is ridiculously fast when run entirely in-memory, etc.
One of the major benefits of something like this, at least for me, is that deployments can easily become non-events. The web services on any given server can be re-started and the applications therein re-initialized without losing stateful data. If the data is persisted to the disk (that is, not entirely run in-memory) then the server can even be rebooted without losing it. Servers/services can drop in and out of the farm and users would never know the difference.
Additionally, externalizing this data allows you to analyze the data in potentially useful ways. Query it, run metrics on it, interface with it via other web applications or entirely offline tools, etc. It really opens up the options as a project grows in complexity.
(Again, this isn't really intended to answer your question, but rather to just add information that you may find useful. It's something my colleagues and I have been tinkering with as of late and your question seemed like a good place to mention it.)
I currently have a custom session handler class which simply builds on php's session functionality (and ties in some mySQL tables).
I have a wide variety of session variables that best suits my application (primarily kept on the server side). Although I am also using jQuery to improve the usability of the front-end, and I was wondering if feeding some of the session variables (some basics and some browse preference id's) to a JS object would be a bad way to go.
Currently if I need to access any of this information at the front-end I do a ajax request to a php page specifically written to provide the appropriate response, although I am unsure if this is the best practice (actually I'm pretty sure this just creates a excess number of Ajax requests).
Has anyone got any comments on this? Would this be the best way to have this sort of information available to the client side?
I really guess it depends on many factors. I'm always having "premature optimization ..." in the back of my head.
In earlier years I rushed every little idea that came to my mind into the app. That often lead to "i made it cool but I didn't took time to fully grasp the problem I'm trying to solve; was there a problem anyway?"
Nowadays I use the obvious approach (like yours) which is fast (without scarifying performance completely on the first try) and then analyze if I'm getting into problems or not.
In other words:
How often do you need to access this information from different kind of loaded pages (because if you load the information once without the user reloading there's probably not much point in re-fetching it anyway) multiplied by number of concurrent clients?
If you write the information into a client side cookie for fast JS access, can harm be done to your application if abused (modified without application consent)? Replace "JS" and "cookie" without any kind of offline storage like WHATWG proposes it, if #1 applies.
The "fast" approach suits me, because often there's not the big investment into prior-development research. If you've done that carefully ... but then you would probably know that answer already ;)
As 3. you could always push the HTML to your client already including the data you need in JS, maybe that can work in your case. Will be interesting to see what other suggestions will come!
As I side note: I've had PHP sessions stored in DB too, until I moved them over to memcached (alert: it's a cache and not a persistent store so may be not a good idea for you case, I can live with it, I just make sure it's always running) to realize a average drop of 20% of database queries and and through this a 90% drop of write queries. And I wasn't even using any fancy Ajax yet, just the number of concurrent users.
I would say that's definately an overkill of AJAX, are these sessions private or important not to show to a visitor? Just to throw it out there; a cookie is the easiest when it comes to both, to have the data in a javascript object makes it just as easily readable to a visitor, and when it comes down to cookies being enabled or not, without cookies you wouldn't have sessions anyway.
http://www.quirksmode.org/js/cookies.html is a good source about cookie handling in JS and includes two functions for reading and writing cookies.