If this isn't appropriate, I apologize, but I wanted to get some feedback on a question I was recently asked during a phone interview. I'm strong on front end development but not very clear on back end programming, something I am trying to remedy.
After I got off the call, I had a bit of l'esprit de l'escalier, I think...
Here's the scenario: You have a simple page where a user is presenting
with a random image and allowed to move it around the page, at the
same time that user can see other users of the same page who are also
moving around their own random images, but no one is allowed to
interact with any other user's images.
So, assuming the LAMP stack is in play and jQuery / JavaScript for your front end, describe how you would implement this and prevent these users from taking control of the objects. Assume the users are savvy enough to watch the post calls in firebug.
I was able to describe a simple interface and control. I was able to describe streaming coordinates to and from a database.
I struggled a bit to think of a good way to protect the information being retrieved while on the call.
After I was off the call, within moments, I thought about a simple method of preventing others from gaining control of this data by not exposing the actual IDs of the objects within the database from which they are called. But I'm still not certain of how to do this exactly. I imagine using a php engine to abstract the variable calls, using random Ids on the objects each user cannot interact with.
This is not something that I have ever considered when working with php / MySQL, but of course I'm thinking that I probably should, even when beating an open source CMS or something into submission.
So, my question is if someone could describe their own thoughts on this or point me to a resource to help me grok this, and how I would use AJAX / PHP to make this work? Am I on the right track?
I haven't heard if I got the job yet, but though it seems it was a primarily front end role, I think they wanted a bit more familiarity with the LAMP than I was able to demonstrate.
Thanks in advance for any help you can provide. Yes, I will be following up with this on my own, and I'm already putting together some plans to dig deeper into php and MySQL for my own edification.
I just took this up as a challenge myself, to try out new technology, and I found it a quite fun little thing to work on. The approach I took was in node.js using mongodb as storage.
Using socket.io, the manipulating was set up pretty fast. As for protecting the objects from external I relied on the session ID, which I linked to the object ID. This way, you can safely expose the ID of the object without it getting compromised.
Do note that the manipulating is limited to following the other cursors on the same page.
http://gist.github.com/ThomasHambach/5168951
Related
I am designing a web application that is heavy reliant on database tables/records and have already designed the login system. As it stands, the login system creates an element in the session to verify that the user is logged on. This works fine.
However, as I've been coding my application--I have found a constant need to check that my users are authorized to perform certain actions.
For example--I have a feature which allows users to edit their profile at www.mywebsite/account/edit/1 -> 1 being the Id. In terms of future scalability, is it practical to perform a database query to check that the current logged in user has access to edit their information after arriving at that URL?
My concern, of course, is that someone would just put in a random Id to edit another account.
I have also thought about creating a form between every transition to post this data, yet that comes with a load of limitations itself.
I was wondering if anyone had hit the same problems and found an overall solution to this problem?
This is a concern that everyone addresses at some point or another. The way I see it, you're really asking a couple of questions:
How do I make sure a user is authorized to access something? and
Is checking the database every single time really the best way to do it?
With respect to the first question: the approach you're taking is probably the only realistic one. It boils down to this: whenever a user needs to do something, your application needs to check something to see if they're allowed to do it. What is that something? It's called an Access Control List (ACL).
You could hard code the ACL in your application, but that's a really bad idea. So that means you have to store the details of an ACL somewhere. And when we start talking about storing something in our applications, the obvious answer is (almost) always in the database.
Which leads to the second question... a quick check of the database to see if a user has access is generally not going to be a huge bottleneck, provided your database design is sensible. You're going to be doing something like SELECT key FROM acl WHERE key='something' AND user_id='current user ID'; and checking to make sure you get at least one result. It's going to add a little overhead to your application, but what's the alternative? Some sort of hard coded ACL? Loading the full ACL for your application and searching it for the key and user ID in your PHP code?
If you're really concerned about the overhead involved with your ACL stored in MySQL, you could look at some of the other databases like MongoDB or CouchDB which should be faster for simple key/value pair lookups (note that I've looked at both MongoDB & CouchDB, but not used either in applications), but I think you'll find that, for most applications, doing it in MySQL should work just fine.
The thing is this, I have several projects where the customer have an horrific backend definition, returning data in several formats and with lot of stuff I don't need. Since Im doing the mobile webapps, Im creating a middle layer in php, using slimframework (www.slimframework.com), which basically give me a RESTFUL syntax also removing all the data I dont need, and in the format I want (JSON). Of course this middle layer will be deployed in customer backend, so even if makes me so easy the frontend implementation, im a little worry about the performance and also adding another break-point to the 'chain'. For performance, every call I get to my slimframework Im saving in a unique JSON data as a cache, and I have a text file where I can configure easily the max amount of seconds of each petition.
More technically, Im reading with curl the real web service, convert to PHP object, remove and change all the data I need and then make a json_encode...also, Ive though another ideas, like creating a batch process in cron that pulls all the web services from customer and generate local jsons... dont worry about not getting the lastest data, since is an video catch up application, so Im caching every WS but the final url is no cached.
Is there any simpler solution for my workflow?
Sounds good to me.
Sure, you're adding a new potential point of failure, but you're also adding a new place at which problems can be caught and handled resiliently — it sounds like the existing back-end cannot be trusted to do that itself. Unit/stress test the heck out of your intercept layer and gain all confidence that you're not adding undue new risk.
As for performance? Well, as with anything, you need to benchmark it and then balance the results with the other benefits. I love a good abstraction layer† and as long as you're not seeing service-denying levels of performance drop (and I don't see why you should) it's almost certainly well worth it.
If nothing else you're abstracting away this data backend that you appear to have no control over, which will effectively allow you complete flexbility to switch it out for something else someday.
And if the backend changes spontaneously? Well, at least you only need to adjust some isolated portion of your intercept layer, and not every piece of your customer-facing front-end that relies on pieces of that third-party data.
In conclusion, it seems to me like a perfectly robust solution and I think you should absolutely go ahead with it.
† of course, you don't want too many of them. It's up to us to decide how many is appropriate. I usually find zero to be an unacceptable answer. :)
I'm refactoring an API where there are user profiles from a profiles table and profile images in a separate table. Currently the API queries the profile tables, and then loops through the images table for associated image data (paths etc). There is logic built in that adds a default img path when a profile image isn't set. So if we are displaying 50 profiles there are 51 queries being run.
I'm considering refactoring where the initial profile query joins the image table. I'm now left with two options.
I can loop through the results server side to build the image paths. I will have to loop through them again client side to display the results.
I can loop through the results one time client side and build the image paths there. The path logic is easy and a simple if statement.
It seems 2 would be the logical choice. But is it? I guess this is part of a bigger question of when you are building out APIs and the client side interfaces when do you move code from the server to the client to keep the API fast at risk of slowing down the browser? How do you do this dance? I'm working on another API using Node for the jquery datatables plugin where there needs to be a lot more code to marry the backend, and it's been a bit of a tug of war determining how much I should hand over to the browser. A fast API is of not much use if you are crashing your visitors browsers.
The tipping for the decision for me, would be
Am I by exposing parts of the component path, so the client can build it, exposing something I don't want to.
vs
Am I by constructing the image paths server side doing work that the client might not need, or that the client might have to redo, like chopping them up on occasion for instance.
In terms of passing more data than is needed, I'm not seeing an issue from what you've said, and the first question would be one with the most priority for me.
Sort of stretching in this scenario, but the client having to know how to compose the image path, sets a few constraints, whereas if it's all done server side the implementation details are hidden. Despite them being simple, that would be my default option
As you've said it's a tug of war. Another way to look at issues like this, is the "right" answer can depend on when you ask the question. You could go one way and them a bit later, some new requirement pops up, and now it's the wrong one....
Simple and consistent is the thing to aim for. Right as in best? 20/20 hindsight time.
When I've seen and done this in the past I've found it better not to store images (like what it sounds like you are doing) in a db. Put them in a place where the browser can link to them and pass the path from the server.
If I understand you correctly.. you are displaying some sort of profiles list where each profile has associated image... right?
Abstracting from the way you store images(db or vfs images are faster but straight files - with at least minor MRU Cache - are easier to maintain).
Solution numero uno is the right way to go.
It is just simpler and more "restful". I am a huge fan of client logic, but we should use it for a good cause(such as Soopa-UI). Same goes for db logic code vs server logic code. I dislike sql and having to maintain another layer of problems, but I do understand the difference it makes in some cases to the final result.
EDIT: Oh... you are storing just paths.
So if you are not doing some fancy one page web app then there is another problem with building paths client side. Client would have to wait for script to finish loading before his images would even start to load.
I have a WordPress plugin, which checks for an updated version of itself every hour with my website. On my website, I have a script running which listens for such update requests and responds with data.
What I want to implement is some basic analytics for this script, which can give me information like no of requests per day, no of unique requests per day/week/month etc.
What is the best way to go about this?
Use some existing analytics script which can do the job for me
Log this information in a file on the server and process that file on my computer to get the information out
Log this information in a database on the server and use queries to fetch the information
Also there will be about 4000 to 5000 requests every hour, so whatever approach I take should not be too heavy on the server.
I know this is a very open ended question, but I couldn't find anything useful that can get me started in a particular direction.
Wow. I'm surprised this doesn't have any answers yet. Anyways, here goes:
1. Using an existing script / framework
Obviously, Google analytics won't work for you since it is javascript based. I'm sure there exists PHP analytical frameworks out there. Whether you use them or not is really a matter of your personal choice. Do these existing frameworks record everything you need? If not, do they lend themselves to be easily modified? You could use a good existing framework and choose not to reinvent the wheel. Personally, I would write my own just for the learning experience.
I don't know any such frameworks off the top of my head because I've never needed one. I could do a Google search and paste the first few results here, but then so could you.
2. Log in a file or MySQL
There is absolutely NO GOOD REASON to log to a file. You'd first log it to a file. Then write a script to parse this file.Tomorrow you decide you want to capture some additional information. You now need to modify your parsing script. This will get messy. What I'm getting at is - you do not need to use a file as an intermediate store before the database. 4-5k write requests an hour (I don't think there will be a lot of read requests apart from when you query the DB) is a breeze for MySQL. Furthermore, since this DB won't be used to serve up data to users, you don't care if it is slightly un-optimized. As I see it, you're the only one who'll be querying the database.
EDIT:
When you talked about using a file, I assumed you meant to use it as a temporary store only until you process the file and transfer the contents to a DB. If you did not mean that, and instead meant to store the information permanently in files - that would be a nightmare. Imagine trying to query for certain information that is scattered across files. Not only would you have to write a script that can parse the files, you'd have to right a non-trivial script that can query them without loading all the contents into memory. That would get nasty very, very fast and tremendously impair your abilities to spot trends in data etc.
Once again - 4-5K might seem like a lot of requests, but a well optimized DB can handle it. Querying a reasonably optimized DB will be magnitudes upon magnitudes of orders faster than parsing and querying numerous files.
I would recommend to use an existing script or framework. It is always a good idea to use a specialized tool in which people invested a lot of time and ideas. Since you are using a php Piwik seems to be one way to go. From the webpage:
Piwik is a downloadable, Free/Libre (GPLv3 licensed) real time web analytics software program. It provides you with detailed reports on your website visitors: the search engines and keywords they used, the language they speak, your popular pages…
Piwik provides a Tracking API and you can track custom Variables. The DB schema seems highly optimized, have a look on their testimonials page.
I am relatively new to PHP, but experienced Java programmer in complex enterprise environments with SOA architecture and multitier applications. There, we'd normally implement business applications with business logic on the middle tier.
I am programming an alternative currency system, which should be easy deployable and customizable by individuals and communities; it will be open source. That's why php/mysql seems the best choice for me.
Users have accounts, and they get a balance. also, the system calculates prices depending on total services delivered and total available assets.
This means, on a purchase a series of calculations happen; the balance and the totals get updated; these are derived figures, something normally not put into a database.
Nevertheless, I resorted to putting triggers and stored procedures into the db, so that in the php code none of these updates are made.
What do people think? Is that a good approach? My experience suggests to me that this is not the best solution, and prompts me to implement a middle tier. However, I would not even know how to do that. On the other hand, what I have so far with store procs seems to me the most appropriate.
I hope I made my question clear. All comments appreciated. There might not be a "perfect" solution.
As is the tendency these days, getting away from the DB is generally a good thing. You get easier version control and you get to work in just one language. More than that, I feel that stored procedures are a hard way to go. On the other hand, if you like that stuff and you feel comfortable with SPs in MySql, they're not bad, but my feeling has always been that they're harder to debug and harder to handle.
On the triggers issue, I'm not sure whether that's necessary for your app. Since the events that trigger the calculations are invoked by the user, those things can happen in PHP, even if the user is redirected to a "waiting" page or another page in the meantime. Obviously, true triggers can only be done on the DB level, but you could use a daemon thread that runs a PHP script every X seconds... Avoid this at all costs and try to get the event to trigger from the user side.
All of this said, I wanted to plug my favorite solution for the data access layer on PHP: Doctrine. It's not perfect, but PHP being what it is, it's good enough. Does most of what you want, and keeps you working with objects instead of database procedures and so forth.
Regarding your title, multiple tiers are, in PHP, totally doable, but you have to do them and respect them. PHP code can call other PHP code, and it is now (5.2+) nicely OO and all that. Do make sure to ignore the fact that a lot of PHP code you'll see around is total crap and does not even use methods, let alone tiers, and decent OO modelling. It's all possible if you want to do it, including doing your own (or using an existing) MVC solution.
One issue with pushing lots of features to the DB level, instead of a data abstraction layer, is that you get locked into the DBMS's feature set. Open source software is often written so that it can be used with different DBs (certainly not always). It's possible that down the road you will want to make it easy to port to postgres or some other DBMS. Using lots of MySQL specific features now will make that harder.
There is absolutely nothing wrong with using triggers and stored procedures and other features that are provided by your DB server. It works and works well, you are using the full potential of the DB, instead of simply relegating it to being a simplistic data store.
However, I'm sure that for every developer on here who agrees with you (and me), there are at least as many who think the exact opposite and have had good experiences with doing that.
Thanks guys.
I was using db triggers because I thought it might be easier to control transaction integrity like that. As you might realize, I am a developer who is also trying to get grip of the db knowledge.
Now, I see there is the solution to spread the php code on multiple tiers, not only logically but also physically by deploying on different servers.
However, at this stage of development, I think I'll stick to my triggers/sp solution, as that doesn't feel to be that wrong. Distributing on multiple layers would require me to redesign my app consistently.
Also, thinking open source, if someone likes the alternative money system, it might be easier for people to just change layout for their requirements, while I would not need to worry that calculations get wrong if people touch php code.
On the other hand, of course, I agree that db stuff might get very hard to debug.
The DB init scripts are in source control, as are the php files :)
Thanks again