I've built a MVC 'framework' for learning purposes, and I'm struggling with this problem:
I am working on a CRUD application and I don't know how I should delete the records from my database. Right now I'am doing it through URL.
example.com/controller/delete/id that is how I delete a record from the database. I don't really like this way, because anyone could unintentionally or intentionally delete database records.
So my question is: How should I implement this feature?
You've got a number of issues here:
First of all, you need to know who is performing the operation, then you need to decide if they're allowed to do it.
For the first, you need a login system which issues a session id to the client (usually via cookie). You then use the session id on the server to look up who the user is and check if they're allowed to do the delete. This is usually handled through granting roles to users and then allowing roles to perform certain actions
Incidentally, GET requests are used for requests that do not modify the server state and can be repeated with no side-effects. POST, (or PUT/DELETE) should be used for any action that makes changes. Browsers will not send a POST twice without prompting the user explicitly.
You need to send data with POST data.
you can also use GET with CSRF token
I think both way is good.
You need to include a security layer to your MVC in order to define who can access specific resources of your API.
The most simple way is to require a key parameter in the URL that needs to match a key that you would have predefined on the server side, but be aware that despite it will prevent random user to update your data, it might not be suitable depending on the security level you want to achieve for your application.
Related
I am working on a system which displays the live status/stages of the system creation.
Example -: If I fill a hosting form then on my form it should display the status of the system. Like domain created, files hosted , etc in a progress bar. I want to achieve this without using data base.
Note: All the operations will be performed on a different system and my hosting form is on a different system.
Hurdles: Multiple forms can be filled at the same time.
What I have tried.
Writing steps to database and read from there.
Do curl post to a specific function. But in that case I have to use DB.
I am looking for a way where there is no db interaction required and I can see the status dynamically after filling the form.
There is 1 solutions for this:
Send and receive information using AJAX from and to server wich has installed software with API
I think this is what you want to do.
Feel free to correct my understanding of the issue, but here's how I see this at the moment.
You have a web site that has multi stage forms. So user fills the first one, then sends it, and gets the next one to be filled.
You also have a web server, probably running PHP, that handles user interaction. So whenever user fills a form, your server application proceeds with that and gives the user the next one.
Furthermore, there are multiple external servers and services that your PHP application gives orders to based on the information given by the user.
You will want to show process information from external services whenever things do proceed.
Finally, you don't want to use a oh so heavy database solution if a lighter one exists.
If I have gotten the facts about right so far, there may be a suitable solution to help you out.
To begin with, it's worth mentioning that PHP has its own session mechanism. Its data storage defaults to flat files, which may or may not be suitable for your use. Yet it requires almost no configuration or setup and offers a persistent storage, so it's by far the easiest option, in my opinion.
Note, that if the amount of information to be stored is very small, you can bypass the application data storage altogether and stick to the cookies. Read on form submit, update during the PHP process and send update the cookie accordingly as part of the response. You can encrypt the data in order to make it harder to alter by the user.
Lastly, there's this option called cache. There are multiple technologies for this when working on PHP. For instance: xcache and APC. These store information in RAM, which obviously has its downsize, since data can basically vanish at any given time - you can control this, though.
No matter the choice of data storage, the general idea is as follows:
When user first interacts with your service, create a session identifier and an approriate cookie to identify the user later on.
When user has filled the first form and sends it, read the information and either store it in the cache or in the cookie. When storing and reading information from and to the cache, either prefix or namespace it using the session identifier used by user. This way there can be multiple users using the service at any given time! When done, send the second form to be filled.
When user eventually sends the second form, read from the cache or from the cookie the information given to the first one. Now, should the information be missing, there has been an error in the filling process (or cache has been invalidated due to long time period or cookie expiration time - you will want to take these things into account, too).
So long things are going nicely, build up your information gathered from the forms. Whenever you have enough information to do so, make a request to the external service to really make things happen.
Now, lastly. You can do periodical ajax requests from the client. Therefore you get not only the forms sent, but also occasional "how is the process going?" queries. Now, whenever you receive a request like that from the browser, you can identify the user by session identifier and make a call from your PHP application to your external service, asking for a status of any kind. You then simply forward the information to the browser that has been waiting the answer all this time.
Note that you may have to store service spesific information in your cache to do this.
This setup, however, effectively gives you the ability to control data flow in your PHP application without revealing the services behind it. It's also lightweight enough to develop as it requires no additional external software for short term data storage.
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.
I'm working out a project that is tightly connected with Facebook. However, I got several questions related to the program flow.
A user may authenticate through Facebook, allowing me to use the user's access_token for data querying. Now, when I need the data, I call the api. This happens more frequently (on different pages, with the fields required to provide the view the needed data). A disadvantage I see is that I query Facebook's API everytime a request is made on one of my website it's pages. Is this a bad thing to do?
Another option would be to store the entire data array in a session (or request it when no session is found) and pull the needed data out of it, and not just the fb id and access token.
If someone has a better idea, or has experience with this, throw it towards me. Any tips are appreciated.
Regards,
matvp.
I guess It's better if you
Query all the data that you may need and Store it in the Session, and use the session further on with your website.
or, Query all the data you want and store it with ID in your DB whatever your DB is, and then also Query your DB whenever you need the data
Sure it is better that you store user data you may need for the entire session, a simple caching of these data let you avoid a lot of queries.
The following Stack Overflow question could help you:
Can you store facebook users' data and for how long?
I have an PHP Application. If I have logged in that application I am trying to pass the parameter as querystring through an iframe to the asp.net page.
Is there any other way to implement other than using an iframe?
Instead of having the PHP application submit data to your ASP application, it would be better if they could natively and securely share some of the data.
How?
Well, your goal is having one script tell the other that the user has been logged in, right? In PHP, this is usually done by putting something in the $_SESSION. Your ASP application can't read $_SESSION, though. You'll need to use something else.
When the user logs in, create a unique value. Maybe the result of hash_hmac over some interesting data? Whatever it is, it should be unique every time it's created and unguessable. Don't throw in things like the user's IP address or the current time.
Save the unique value to a database table that both applications can read. Also store other information that will help identify the user, such as her identifier (user_id or whatever you have on hand).
So, the PHP code that logs the user in has created this unique value and stuck it in a shared database table. Now, the PHP application should forward the user to your ASP application. Include the unique value in the request.
When the ASP application receives the request, it will look for the unique value. If it's found, it can look in the shared table. If the value is found in the table, it can then take whatever measures it needs to in order to mark the user as logged in.
Once the ASP application has logged the user in, then it should delete the unique value from the shared table. The user can be forwarded to wherever she was going in the first place.
By making the key usable only one time, and only after a successful login in the PHP application, you'll reduce the possibilities of abuse by malicious or curious users. All of the important information will be hidden in the shared database table.
Be warned that this is an overly simplistic implementation of "single sign on" and is full of caveats and edge cases. While it might work for you, it might not be the best solution. Given your question history, it looks like you've been struggling with similar issues for quite some time. You might want to give some thought into using a slightly more "industry standard" SSO mechanism. SAML is the 800 pound gorilla of SSO standards. I normally wouldn't wish it on my worst enemy, but maybe it's the thing you're really looking for here.
Also, don't use iframes, they're cookie eating disasters in some browsers.
We are developing a very simple first stage GUI for a company database.
At the moment our time to deliver is rather limited.
So we thought about using a simple SQL stored procedure and retrieve all data.
The data the users are allowed to see is depending on security levels defined in the database and also in our Active Directory.
So after fetching all the data, the GUI displays only what the user has access to view / edit.
My question is if there are any remarkable security issues with this aproach? It should also be noted that both the webinterface and the database are located in our intranet.
Our backend uses W2K3, IIS, PHP 5, SQL 2005
Any feedback would be greatly appreciated
Jonas
Considering the time to deliver (about 1month), it should be rather ok.
First thing: since it is in intranet only, your site should be rather secured since outside world cannot be accessing your site.
secondly, XSS and cross site request forgery should be disabled no matter what.
next, SQL injection.
with these few things in mind, the application should be basically secured.
Don't put an outward facing web server on your internal network. Seriously. Put it in a DMZ.
As far as your data is concerned, will you be filtering based on user access before or after the data hits the web front end? I'd suggest doing it in the proc.
Also, if you can, I'd suggest putting your DB on a separate box as well, for added security.
It is a sound enough approach. This way the data the user is not allowed to see remains in the database.
"So after fetching all the data, the GUI displays only what the user has access to view / edit."
A frequent mistake when dealing with access control on websites is implementing them for the data fetching scenario but not the data writing scenario. This is often the result of the assumption "the user will only send us editing requests on resources that we told her she could edit". Unfortunately...
As I coudln't spot this in your question's content, I'd just recommend making sure you effectively dealt with access control when building the GUI but also when receiving data modification requests.
If we consider the following scenario:
The user fetches data she has legitimate access to.
The user requests edition of that said data. Let's imagine an edition form is now displayed.
The user submits the form with the changes.
Before leaving her machine, the user intercepts the HTTP request and replaces the identifier of the edited resource by another identifier, to which she shouldn't have access.
Does your model ensure that when receiving the editing request, the access control rules are also applied? From a SQL-like scenario, this would translate to asking whether you're using a request template such as the first one below or the second one below:
1) "UPDATE ... WHERE ID = x"
2) "UPDATE ... WHERE ID = x AND (SELECT ... FROM ... WHERE userID = y)"
If your model is more likely to be the first, then you might have an authorization model issue. Else, it should be okay.
Hope it helps.
sb.