I am using cakephp 2.1 and I have written some actions like view, edit and delete.
In url it looks like 'view/1', 'edit/1', 'delete/1', So that I can change the ids in url.
I don't want to change it in url and it should not allow to edit the ids. Please help me to do that. The work will be more appreciable.
OK... I think I understand your question. You are concerned that if people can edit the ID's, as they are visible in the URL's, then it will be a security threat?
First, view actions:
You should check on the server-side if the user has permission to view the record with that particular ID. If they don't, then you can give an error. If they do, then let them view it - don't worry about how they got there, whether they edited the ID in the URL or not. If they have permission to view the record, just let them view it.
Second, delete actions:
Again, just like view actions, you should check on the server-side to see if a user has permission to delete the record. If they do, then let them delete it! Don't worry if they edited the ID in the URL. If the user doesn't have permission to delete the record, then your server-side check will stop them, even if they've edited the ID in the URL.
Third, edit actions:
This is slightly more complicated, but still pretty easy. I'll assume you're editing a record with an HTML form, and submitting via POST. OK, so the ID in the URL determines which record to fetch and edit. As with view and delete, you should do a server-side check to make sure the user has permission to edit that item. If they do have permission, then return the form.
Once the form has loaded, the URL showing in the browser is of no importance. The URL which the form submits to, and the data that the form submits, is important. Now, by default, the edit form will store the ID in a hidden input field. A user could change that ID, and thereby change the record they are editing.
To prevent this, use CakePHP's security component. All you need to do is include the component, and CakePHP will automatically put a hash on the form when it's loaded, which it will check again when the form is submitted. If a user has edited hidden input fields, this check will fail, and CakePHP won't allow the edit to go ahead.
Note that to use the security componenent in this way, you must build your forms using CakePHP's form helper (which you probably already are).
And a final note... sometimes people are a bit paranoid about anyone seeing the ID's in their database - and therefore don't want them showing in URL's or anywhere else. But, in almost all cases, there's nothing 'secret' about ID's at all. It doesn't matter who sees them. All they are is a means for your application, and the database, to identify a record. So long as your application is secure, then you should be able to show all your ID's to the whole world, and have nothing to worry about.
Related
I'm still on the conceptual stage of this problem, so I'm open to suggestions on how to go about solving the problem. The problem is this:
I have a web form. Users are editing data. When they submit the changes, I need to determine which fields are different, and then collect additional information for each field, like, find out why they changed a value.
I'm not allowed to use javascript to handle this task because some users will have javascript disabled.
So, how do I request additional information based on information already submitted, and how do I keep all the information straight so I can submit it all to the database correctly once it is all collected?
I can see submitting the changes, and then in the controller checking against the database (or hidden fields previously given to the view) to figure what fields are different, but then I don't know how to request additional information of the user based on that.
I agree with the approach of checking against the database to see which fields have changed (if you use hidden inputs remember that those can be tampered with - if your application is critical you'll want to avoid that). Once you know that something has changed, I would persist the new user input somewhere (disk, session, database, etc) so that you can access it later to actually persist it in the existing record in the database.
If you need to request additional information, once you've stored what the user submitted just return another view and form for the user to submit back to you. Depending on what your needs are, if you need to get a description for each field, perhaps just build a collection of fields that have changed and iterate over that collection in the view to ask for input.
In my Rails App, I made a form_for to allow any visitor to submit their content.
But after submit, I want to ask user, whether they want to register for this site or not.
There are some approach to this:
Redirect after user submits the form, left the initial post anonymous.
Much the same as the first one. But somehow help user to reclaim the post they just make
Store the content in some place first and do not submit. Instead, ask for register. And after register, show the stored content before and ask user to submit again.
Basically, I can implement the 1st method. But it seems just not that good. For the 2nd and 3rd one, I do not know how to reclaim the post or store content beforehand.
Is there a standard way to do this? How can I solve this problem?
For solving the same kind of problem, I chose your 3rd option. For that you can use sessions, it will allow you to keep some information in memory related to a specific connection to your server.
http://guides.rubyonrails.org/action_controller_overview.html#session
There are some ways.
First of all you need to keep in mind that these are different behaviors from which you should chose first and do not let the implementation force you to chose one.
For the second case you can have the id of the post that was created (along with some guarantees that it is an orphan post) and then tweak your register method to also assign a post to a user after creating one.
The Third case can be implemented by storing the post data either to session or to a backend temporary store and retrieve them if needed.
To generalize this question I asked this morning, and please accept my apologies if this has been asked before and I simply don't know what to search for, but I'm curious how Rails handles the following situation:
Using Devise, I log in a user, with an ID of 2.
I click on a link that has been created to "edit my profile" (which simply would go to the /users/2/edit page).
Using Firebug (or something similar), I modify the form and change the action from action='/users/2' to action='/users/5'.
I change an element on the form, and click submit.
At this point, Rails appears to allow the submission and update user with ID 5 with my changes.
I'm guessing I'm not the first one to ask this question. It seems to me like Rails should handle this "out of the box", but I could be wrong. Does Rails handle this natively and I'm just missing something? Has this been asked before on SO or somewhere else that I'm missing?
A few things:
Don't create a route that accepts a DB id. Instead, make it something like /my_profile.
If an id is passed in the params, ignore it entirely in the controller. Instead lookup the current_user that is logged in and show them their own profile regardless of what profile/user id is passed in.
Finally, and possibly most important, use authorization (what a user is allowed to do) in order to disallow one user from editing another user's profile. Not to be confused with authentication (user logins/logouts).
With this approach it won't matter if the DOM is changed, because the server should never implicitly trust what is passed to it, which is the problem you're facing now. Any web/app server must always confirm that the parameters being passed to it are actually valid in the context of what the current user is allowed to do.
This idea that the server should never trust what's passed to it is a critical idea to apply to every single action in your app, without exception.
We have been using asp.net mvc for development. Sometimes, we need to put some hidden fields on form that are shoved in the model by modelbinder (as expected). Nowadays, users can easily temper the form using firebug or other utilities. The purpose of hidden field is mostly to provide some information back to server on as is basis and they are not meant to be changed.
For example in my edit employee form I can put EmployeeID in hidden field but if user changes the employeeID in hidden field, wrong employee will be updated in the database. in this scenario how can we keep the integrity of hidden fields.
You need to enforce security to ensure that the person doing the modification has permission to do so. I'd also put the id in the URL typically rather than a hidden field, relying on the security to ensure that people don't modify things that they shouldn't be able to. If they do have permission to modify the item when changing the id manually, it shouldn't be a problem. The important thing is to make sure that a person can't change the id manually and get access to something they shouldn't. Enforcing server side permissions solves this problem. You can easily do this using Roles in conjunction with the AuthorizeAttribute.
if user changes the employeeID in
hidden field, wrong employee will be
updated in the database
This is a major security hole in your website. In everything you do with web development, no matter how clever someone's code might be or how much you think you'll be ok as long as users don't do something, remember one golden rule: Never implicitly trust data received from the client.
In order to modify anything in your website, the user must be logged in. (Right?) So in any attempt a user makes to post a form to the website (especially one which can modify data), double-check that the user submitting the form has permission perform the action being requested on the data being specified.
Ideally, every action which isn't completely public and unsecured should have a server-side permissions check. Never, ever trust what the client sends you.
One potential alternative would be to store that static, single-use information in TempData on the server and not pass it to the client where it could be tampered with. Keep in mind that by default TempData uses Session and has limitations of its own - but it could be an option.
I have a form where the user can choose options from a lot of select boxes. The form is used to register several items from an RSS feed. The user fills in the form, clicks create and is presented with the same form for the next item in the list.
Sometimes, the same options are valid for several items in the list, and I would like to be able to save some of the selections done so the user doesn't have to make the same selection for the next items.
What is the best way of doing this? I've identified four ways of doing it:
Sessions
Just keep the values in the session hash. This will of course work and is very simple, but I have some undefined feeling that it is a bad idea. It will also not work if the user is using the form from different tabs in the browser.
Cookies
Basically the same as keeping them in the session, I think.
Profile
Can't be done in this case I believe, since profiles are shared between several users.
Database
The most complex way I've come up with is to keep the information in the database and use a query parameter to keep track of which information should be used. This is probably overkill, but in some ways the best way to me. I don't like the idea of keeping this kind of state in session or cookies.
Am I missing some way? Or something?
If after filling first form, some data is saved to db (object is created) then you can use this data from db to fill up new form.
If after filling first form, nothing is saved to db, then you can create in memory some objects based on params from previous post and based on this (on just on params) you can prepare new form. But of course data from previous form should be added as hidden fields in second form.