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.
Related
I am trying to restrict the user from downloading the page as .html or .aspx file from browser.
Or is there a way to change the content of file if its downloaded?
This is a complex area, with lots of moving parts. The short answer is "there is no way to do this with 100% success; there are a few things you can do which make it harder".
Firstly, you can include JavaScript to disable the right click context menu. This doesn't stop Ctrl+S, but might discourage casual attempts.
Secondly, you can use DRM in the browser (though this is primarily aimed at protecting media content. As browser support is all over the show, this isn't realistic right now.
Thirdly, you could write your site as a single page web application, and build some degree of authentication into the "retrieve content" logic. This way, saving the page to disk wouldn't bring the content along, just the "page furniture". However, any mechanism you include to only download content when you think you should is likely to be easily subverted by anyone who is moderately motivated.
Also, any steps you take to stop people persisting your pages locally are likely to break the caching mechanisms on which the internet depends for performance, so your site would likely be dramatically slower.
No you can't stop them.
Consider how the web actually works here: once the user has visited your website and loaded your page into their browser, they have already downloaded it - the web page was transmitted from your server to their computer and appeared on their screen.
All they have to do then is click the Save button to keep it permanently on their disk. That doesn't involve downloading it again, it just copies the page data from a temporary folder to a permanent one. Of course it's also possible for people to use another HTTP client (i.e. not a browser, but maybe an existing program, or some code they wrote themselves) to visit the URL of your page and save the returned contents.
It's not clear what problem think you would solve by stopping people from saving pages. Saving the page is something done within the browser - you as a site developer don't control the user's browser, so you can't prevent that. And if you stop them from downloading your page in the first place then - by definition - you also stop them from using your website...which kind of defeats the point of having one :-).
If you've got some sort of worry about security, you'll have to clarify exactly what you are concerned about, and maybe you can get advice about a sensible way to deal with it.
I've been looking over the net, trying to find some body else who has had this problem before me, but nobody is describing the exact situation I'm in. Others have dropping session states that stay out, or they have short session states as in like 5 minutes, or something of that nature. My issue however, is that my session state variables seem to be there for one postback, skip out on the next one, and be there again for a third sometimes.
You can log into my website: EpicClanWars.com and then maybe refresh a few pages, then after the 2nd or 3rd different page, you get the login text boxes in the upper right like you are not logged in. But then if you refresh the page again, the site will show you as logged in again.
I am assuming this has something to do with the viewstate, but I don't know much about the ASP.NET viewstate or how to troubleshoot it. To support this, I've received a couple of error messages (which I sadly neglected to save for this post) which pertained to MAC problems, and viewstate problems.
I recently had to reinstall the OS on the machine running my site. When I did that, I reinstalled visual studio, IIS, SQL Server, everything. Before the re-install I did not have this problem. I am using VS.NET 2005, and IIS 7.
What is going on here?
You can log into my website:
EpicClanWars.com and then maybe
refresh a few pages, then after the
2nd or 3rd different page, you get the
login text boxes in the upper right
like you are not logged in. But then
if you refresh the page again, the
site will show you as logged in again.
This is a cache issue. From the moment you have dynamic pages and keep the login on every page, then you need to absolute not keep cached page on client. So your client just read a cached page, after the update its get the new one.
On your page you give you have also a dns issue with the www., check it out and make it work. You need to redirect the www.epicclanwars.com to epicclanwars.com, if you won to keep only one copy. At this time the www.epicclanwars.com, just not working at all.
The "In Process", thats keeps them in memory is not so accurate on a shared environment and maybe lose the sessions if your computer runs on his limits or if you have many restarts of your pool for any reason. Maybe if you not solve the problem with the cache on pages, to think also to move the sessions on the database.
Also check on web.config the sessions, httpCookies, forms, roleManager, must have the domain="epicclanwars.com"
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.
I am using ASP.net with C#.After I logout its possible to go back to pages using back button.I could fix the prob for the login.I have prob with the logout.I am using the inbuilt login page provided by the asp editor.Should I use sessions?
please help.
This is a caching issue. Browser will be loading the page from cache. You can disable caching of the Home page, and check for user session in that page. By this you can avoid the problem.
See HttpCacheability Enumeration
On all pages in your site, you need to check if the user is still logged in and if not, log them out.
You also need to make sure that the pages are not cached on the browser on anywhere else.
After using the back button, try doing some process that needs login privilages. I think you are logged out already but your browser is displaying your page from the cache.
As #Rahul has identified this is a cacheability issue. Basically what is happening is when the user visits the page the browser is caching it. So regardless if the user is logged in/out, when the user selects the back button, the page being retrieved from the cache not the server.
If you want to ensure the page is always retrieved from the server (which will effectively resolve your issue) you need to set Cacheability to NoCache. See Setting the Cacheability of a Page.
See Login on the Web. The same principles apply.
I used history.forward() in the header of the web page, which I didn't want to be displayed.
It is working.
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.