I'm guessing no. Here's the situation I have in mind:
form action='/12345/destroy', method='POST'
- if #current_user.kind_of? Admin
button
- else
span You cant do that
What's the better way to go about constructing a page like this? Create a controller for those "in charge" and have the buttons there? What if the admin chooses to disallow some users from using the delete button, are we back to square one? Thanks
Your example is perfectly fine IMHO, but it really depends on your requirements. If you think that someday there will be the need for more kinds of users and you're afraid the views could get messy, I'd recommend looking into an ACL library. Alternatively you can always roll your own authorization layer.
Your view is fine, but obviously, it is in no way secure. You have to check the privileges in your "controller" (if you have one) or in that request's receiving end.
Also, that logic will probably be used in more than one place. You might consider extracting it into a helper method.
form action='/12345/destroy', method='POST'
= render_destroy_action_for #current_user
Once you have that logic hidden in a method, it will be easier to change later.
Related
We've got a few emails that get sent out by our ASP.NET MVC 3 application.
In one of the emails, we want to add "Did you find this helpful?" to the footer of the email.
If they click "Yes", some action needs to be taken in the database.
What approach should i take for these links?
I don't really like the idea of doing a GET (e.g when they click the link), which then adds something to the database. GET's should never update state. Is there a way i can make it do a POST instead?
I'm using ActionMailer to perform emails, if that matters.
EDIT:
To be clear, i'm how asking "how" to implement the MVC side of things. I know i can create an action which takes the id, etc and saves to the DB, but i'm asking about what is the correct approach from a REST-style point of view.
You can create a form and do a POST in an email but it wont work with certain mail clients. Here is a reference from 2007 that shows where it works and where it doesn't:
http://www.campaignmonitor.com/blog/post/2435/how-forms-perform-in-html-emai/
ETA: A POST would of course fit the REST pattern but probably not a good option in your case. Since you are presumably just incrementing a counter for helpfulness, having this URL exposed shouldn't cause much of a problem.
I use codeigniter as my framework and in the top of my controllers I am going to add a line of code that will send the uri_string (the last page the user requested) to a library which will send it into the users session and possibly eventually into a database.
My question is whether or not I need to validate this uri_string() at all or whether it is safe as is?
Simple answer, if in doubt validate it.
For the short time it will take you to code it you will have peace of mind.
Also, if this is going to happen for all you controllers may I suggest that you either add the function call to the construct of each controller or extend the core controller to include the call in its construct.
Keep in mind that the 'permitted_uri_chars' item in config.php will automatically prohibit any URL that contains non-permitted characters. So, as long as you haven't modified that to include potentially malicious characters, you should be ok. From the comments in config.php:
By default only these are allowed: a-z 0-9~%.:_-
However, as Rooneyl mentions, it probably wouldn't hurt anything to sanitize it anyway.
We usually follow the convention of doing a redirect after every post, which is ideally very clean. But usually there is a requirement to give the user feedback about what has been updated.
When i do a post followed by get i wanna show the same page with the notification about the updation being done, which makes the GET very clumsy with the extra status of whats being updated. Am i missing something here?
which is ideally very clean
debatable.
which makes the GET very clumsy with the extra status of whats being updated
...and that's one of the main reasons why.
Trying to pass transactional data via the session is a very bad practice.
The solution I've used is to use a front controller for sequences of forms (not a front controller for the whole site!) but in general trying to avoid the scenario where there is a sequence of forms to be posted
A bit of context: I need to cache the homepage of my CakePHP site - apart from one small part, which displays events local to the user based on their IP address.
You can obviously use the <cake:nocache> tag to dictate a part of the page that shouldn't be cached; but you can't surround a controller-set variable with these tags to make it dynamic. Once a page is cached, that's it for the controller action, as far as I know.
What you can usefully surround with the nocache tags are elements and helpers. As such, I've created an element inside these tags, which calls a helper function to access the model and get the appropriate data. To get at the model from the helper I'm using:
$this->Modelname =& ClassRegistry::init("Modelname");
This seems to me, however, to be a kind of iffy way of doing things, both in terms of CakePHP and general MVC principles. So my question is, is this an appropriate way of getting what I want to do done, or should it ring warning bells? Is there a much better way of achieving my objectives that I'm just missing here?
Rather than using a Helper, try to put your code in an element and use requestAction inside of the element.
see this link
http://bakery.cakephp.org/articles/gwoo/2007/04/12/creating-reusable-elements-with-requestaction
This would be a much better approach than trying to use a model in your helper.
Other than breaking all the carefully-laid principles of MVC?
In addition to putting this item into an element, why not fetch it with a trivial bit of ajax?
Put the call in its own controller action, such that the destination URL -> /controller/action (quite convenient!)
Pass the IP back to that action for use in the find call
Set the ajax update callback to target within the element with the results of the call accordingly
No need to muck around calling Models directly from Views, and no need to bog things down with requestAction. :)
HTH
Are there are any rules for when to use Client-Side validation and when to use Server-Side?
The right answer is probably use both.
Client-Side validation is faster and should be used as much as you can before submitting the form to the server.
BUT! You can't count on client-side validation since there are easy ways to go around it, so you need to repeat all the validations on the server-side and add new validations if you need (for instance: using database to add more validations etc.)
It is ok to use client-side validation for convenience. You should always validate critical info on the server though, since client's can be circumvented.
What happens if javascript is disabled in client's browser?
So go for Server side validation.... I think there is no rules for validating on client/server... Its upto you and your users....
its better to validate both sides for better peroformance and it would be secured , as it avoids duplicate entry , we would know that, data entered is correct at any point of time . Client side is always good and its mainly for User interface for the user to know the what is right or wrong .
One more thing if we are writing our own stored procedures than its better to write validations on proc side so tht message can be passed through output parameter also .