Fill the form with data
Proceed to fields' validation
if the validation pass, go to the a different.
In ASPNET NVC, I can put my data in Tempdata["myKey"] and recover it somewhere else.
How can I obtain the same result in WebMatrix?
Thanks for helping
There isn't a direct equivalent. You can use Session instead.
Related
I know I must use HtmlEncode() on everything that's displayed (Labels, etc.)
Do I also need to use it in my data-bound buttons' CommandArgument ? (even though I can't, on input, trust them to still be so)
I finally found my answer here:
https://stackoverflow.com/a/20791870/1455631
The CommandArgument, as well as the CommandName are not sent from the client side to the server. They are Stored on the LinkButton's Viewstate and retrieved on the server side. In this case, the __EVENTARGUMENT Form Key will be empty.
Which means, there's no need to sanitize CommandArgument.
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.
i was reading about AntiForgeryToken but do not understand the actual use or importance. i saw people wrote a code like in their form as
#using (Html.BeginForm("Create", "Register"))
{
#Html.AntiForgeryToken()
}
so what it does....it will generate a unique token and when form will post then this unique toke will pass and as well as a cookie will pass with same unique token value and two unique data will compare at server end that both are equal or not. if not then some tamper occur.
i just do not understand if other form field value change or tamper then how that tampering can be determine. suppose we often store valuable data inside hidden fields. if i need to secure that hidden fields value then how AntiForgeryToken can help us?
can we use AntiForgeryToken to wrap up those valuable data inside it and later compare at server end.
can anyone give me bit of sample code by which i can put 3 valuable data in my page and if tamper then a friendly message will be show to user. guide me how to do it. thanks
The idea behind the AntiForgeryToken is to prevent data being posted from a "fake" source. An attacker using a fake (forged) form can trick the user to submit any kind of data using their current session context. As you can imagine this can do quite a lot of damage.
A way to prevent this is to have a hidden field on your forms containing user specific data(something random) that is stored in the session, so that the bad guys can't forge it. In this case when a user posts the data, but doesn't have the user specific token, you can treat is as being malicious.
I think you have a misconception that the anti forgery token is about detecting whether the data posted has been "tempered" with, which it is not.
Here is more on this.
I am currently using the CodeIgniter framework, and looking to strengthen the XSS protection by using HTMLPurifier (http://htmlpurifier.org/).
Is my understanding correct that you want to 'clean' data on post, so that its purified before its inserted into the Database? Or do I run it before displaying in the view?
If so, do I want to run HTMLPurifier on every single post that takes place? Since the app contains a lot of forms, I'd hate to have to selectively choose what gets cleaned and what doesnt - assuming that I can intercept all posts, is this the way to go? Of course, I validate some fields anyway (like email addresses, numeric numbers, etc)
Use $this->input->post() to get $_POST data. Codeigniter filters it automatically if global xss filter is set to true.
See the docs: http://codeigniter.com/user_guide/libraries/input.html
Edit: to clarify
Yes you should filter before inserting into the DB and yes you should filter all user input.
A quick google search, http://www.google.com/search?q=codeigniter+htmlpurifier, led to this page: http://codeigniter.com/wiki/htmlpurifier which is a helper for htmlpurifier. Regarding catching all $_POST data: you have to do something with the data, right? In your models, when you're doing that something, just make purify() part of that process:
$postdata = purify($_POST);
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 .