I have not found the same as or related to my question above.
If it is already asked, please let me know, I will delete mine.
I am learning asp.net mvc 2.
After downloading the rendered page, the visitors have a chance to manipulate the html contents ILLEGALLY and submit it back to the server. In MVC, how can I avoid this issue?
You cannot prevent anything on the user side. Therefore you must ensure that the server reacts correctly to manipulated input.
Note that the automatic model binding is tricky: both over- and under-posting can cause trouble.
This is an excellent post on that topic: http://bradwilson.typepad.com/blog/2010/01/input-validation-vs-model-validation-in-aspnet-mvc.html
Take all the efforts you can to validate the user input at the server. MVC offers the AntiForgeryToken which helps verify that the page being posted back is the correct page but as with any client-side verification, it's not foolproof.
You can't do anything about this.
Use the mantra "never trust anything from your users" and validate everything on server side.
Related
I want to create a quick page load response in ASP.NET MVC .
If I use [outputCache] then it saves the whole page with the dynamic parts and then a new client will see previous client information.
What is the Best Practice to Do It?
I saw that there is a Cache Tag Helper but will it be faster?
Because I still have to go into the Action and and rendering the page except for the section of the Cache Tag Helper.
Many thanks to those who have an optimal and fast solution.
In the docs for response caching, Microsoft has a prominent warning:
Disable caching for content that contains information for
authenticated clients. Caching should only be enabled for content that
doesn't change based on a user's identity or whether a user is signed
in.
As you indicate, your scenario involves dynamic authenticated content. Thus you should avoid caching the rendered output as a whole, and maybe consider caching specific data or elements within a page only if you're very careful and performance requires it. Otherwise, safer to leave defaults. ASP.NET Core is very fast -- it's unlikely the rendering is the bottleneck in most cases.
I have a problem in my asp.net pages
We are using form authentication. Once page is signed out I am able to go back to the previous page. This is due to pages cached in browser.
So i disabled the cache. But this has its own drawbacks.
If user is logged in he will not be able to navigate to the previous page using back button since no cache available in the browser.
if I have a file download in the page it wont work since cache disabled.
Even history.back javascript function also not the correct solution.
What is a permanent solution for this problem? I have faced with this all the time and never found a consistent solution.
Can anyone suggest a possible solution for this?
Thanks
SNA
You shouldn't need to disable caching. If you invalidate their session or authticket, you should be able to detect if they are signed out or not, in which case you can redirect them. This link may be helpful. If you are really concerned with the back button try using clearing the clients history via javascript after you log them out.
EDIT
Check out This Link It goes in depth on some of the different approaches. I don't think there is a sure fire way of keeping users from looking at previously downloaded content, but there are a few things you can do to make it difficult.
I have an ASP.Net 3.0 SP1 app that uses Form Authentication.
While testing, I noticed that if I viewed a page that another user was viewing, the other users name would be displayed in the control on my master page. The Context.User.Identity is also for the other user.
If I switch to different page that no one else is viewing the Context.User.Identity is correct.
I stumped and would appreciate suggestions.
Thanks in advance.
Chris
Maybe because output caching is enabled for the page: if the page is cached server-side with VaryByParam=none, all users will get the same copy from the cache.
I can only think of two things that can cause this:
You're storing user-specific data in a place shared between requests (e.g. in a static(C#)/shared(VB) variable, in the ASP.NET Cache, in the Application object, ...)
You have output caching enabled.
Check for:
OutputCache directives in your aspx and ascx files,
system.web/caching element in your web.config file(s),
Calls to the HttpCacheability.SetCacheability method.
If you can't find the problem:
Try creating a simplified version of your application until you get the simplest possible version that still reproduces the undesirable behaviour.
During this process of simplification you'll likely discover the problem for yourself. If not, post some code from the simplified version.
Make sure you are not using a link that comes with the authentication ticket when using a cookieless browser.
Also make sure to review any other that might be sharing the data among requests. Just like DOK said, but remember Application isn't the only way you could be doing that.
It looks like the issue was caused because I setting targetframe="_self" or Target="_self". I removed all these and everything seem to be working fine.
One other note: If I were to refresh the page it would also display the page with the correct user.
i noticed that a forms authentication element has an option child element called Credentials.
MSDN Online explains what it is, here.
That said, i don't understand what it would be used for? So i can add in a username and password (either clear/md5/sha1) to the config file.. but how/when is it used?
Is that an example of hard-coding in a username/password to be used with forms auth, instead of having a database? If so, is there any code behind? What happens if you also have a database with users/passwords?
cheers :)
You're exactly right... hard-coded username/passwords. That's it in a nutshell. Only time I've actually used it is on a project where we wanted to work on some code that required authentication, but didn't have the real mechanism wired in. It's just a placeholder for real authentication so far as I'm concerned.
MSDN seems to agree, given the warning note at the top of the docs you link to. You can use it side-by-side with a DB, but why bother?
I've inherited a DotNetNuke site that was built and managed by someone who thought storing user passwords as plain text was a good idea because he could easily look up a password and tell the user what it is if they forgot it and to log in as them if they had an issue. After recovering from my heart attack at discovering this and getting my mind to navigate away from the idea of how stupid that is, I need to fix it.
I know to change the web.config settings to use the correct password configuration, but was hoping someone else that's had to do this with a DotNetNuke site might provide some guidance on the best way to approach this. Should I just use standard .NET code and write an app to cycle through them and change them or do I need to use the DotNetNuke user objects? Any article links or sample code would be really helpful. I've found posts about doing this generally but not in the context of a DotNetNuke site and am unsure if there's any special considerations I need to take into account.
Sadly there isn't any real documentation that I'm aware of that would handle this. My recommendation would be to make the web.config change to hashed. After doing this user resets will start using the new format.
You could then write a simple module that grabs all users with plan text and resets their password using the ChangePassword API call from the UserController API. It isn't elegant but would get the job done.