I have a wierd situation where I have an ASP.NET page that sends the user to the ASP page, and data is passed from one to the other via query string.
I've been assigned the task of changing this so that cookies are used instead of query strings.
I'm a little clueless here. Is this possible? How do I get started? Do I need to worry about anything special because one page is ASP.NET and the other ASP ? I also cannot be totally reliant on Javascript because of those once-in-a-while user visitors who have Javascript turned off.
This is pretty simple.
As long as you are not setting a 'Session Cookie', the cookie is set on the browser.
I'm doing it here...when the user logs in and wants me to remember his username:
Set the cookie in ASP.NET:
Response.Cookies.Add(new HttpCookie("RememberMeUserName", owner.Username));
View the value in ASP:
Response.Write(Request.Cookies("RememberMeUserName"))
Both the ASP.NET & ASP pages must be on the same domain name.
Ed B seems to have it - further reading available here:
http://ryangaraygay.com/blog/post/Updating-ASP-cookie-from-ASPNET-vice-versa.aspx
I also found this : http://www.eggheadcafe.com/tutorials/aspnet/198ce250-59da-4388-89e5-fce33d725aa7/aspnet-cookies-faq.aspx
With gotcha's concerning IE 6 and fixes! Also has information on how to store multiple values in them.
Related
Let's assume I have a profile page where DropDown is shown and 1 Admin user can change role of different user.
Eg:
2 - Admin
3 - Member
Assume that 1 is for SuperAdmin. If we have a DropDownList in Asp.Net and bind it to datasource in code behind and then mysteriously try to change values in DropDownList and then submit the form we get exception due to EventValidation. However in Asp.Net MVC if we edit it would definitely because it embraces the web. Is there anything I could do to prevent this kind of cross cutting things in my web applications?
One of thing I could is to check when the form is posted to see if value posted is either 2 or 3 and if not display some message like "Are you trying to hack". Are there any better alternatives?
The solution you mentioned (checking on server) IS the correct solution to prevent such hacks on web sites of any kind.
Using firebug is not the only option to "cheat" javascript based validation. It can also be done with any basic sniffer tools, such as fiddler, which can help a potential hacker to analyze the posted data to ur site, change it in a whatever way he wishes, and then to post it again, using the browser or his own networking tool.
I usually use both the validations (script and server side) in all the scenarios, while the client side validation's main purpose, in my opinion, is to prevent postbacks to server (which will annoy a normal user) when i can already tell on the client side, hes doing something wrong.
Such validations, however, can never be secure enough to guarrante the data is to be automaticlly trusted on server, as its too easy to modify javascript/ posted data, to override them.
EDIT
Following the resposne of UnhandleException:
In MVC specificly, you can use the Data Annotation attributes, to make the mvc engine render client side and server side validation for u
This tutorial explains how do use the attributes validation in ur mvc apps
Do not rely on client side validation. Build a validator for each input. Place the set of validators on the server-side of your application. If there are validators on the client-side, make sure the same validators are implemented on the server-side as well.
Here inputs means URL-based parameters, Form-based parameters, Hidden fields, Cookies ets.
I'm working on a business application using ASP.NET Ajax , NHibernate and Spring.Net, I've got an annoying problem. The problem is that when I leave page for about 5 minutes and then return back and try to make any action that posts back, it displays wrongly (if there are controls hidden by style it became visible). In addition, the page didn't post back to the server.
Also the problem happens when opening two different tabs, different pages (Each page uses session but different keys )
Thanks in advance
As you describe the problem, its sounds that connect the content of the page with the user cookie and session, and when the session expired the application did not take care to recreate it.
So the post back fail because the session data have been lost when the page ask for them / need them to work and display correct the results.
This is the issue that I diagnose, how you fix that is up to you :)
Possible solutions
Change the logic of the page creation.
While the user is on page do not let the session ends (not good practice)
Store the user data of the page, on a database - connected with the user, and delete it after some days if not have been updated.
I've inherited an old Asp.Net website (I've had limited exposure to Asp & Web stuff).
One of the pages takes values from a query string, does some giggery pokery with them and then re-directs to another page.
The existing code has some Session State logic in there to remember the giggery pokery in case of PostBacks, but I'm wondering if it's necessary.
Can a page that always redirects be posted back?
Apologies if this is a dumb question
If it always redirects then no it cannot receive a postback, (from itself)
there are details of the page lifecycle here:
http://msdn.microsoft.com/en-us/library/ms972976.aspx
Sure, it could postback, but how is your setup? Without seeing, it's hard to give you any definitive answer.
Thanks.
I have an ASP.NET website where i have implemented page level caching using the OutPutCache directive.This boosted the page performance.My pages has few parts(Some buttons,links and labels) which are specific to the logged in user.If user is not logged in,they will see different links.Now Since i implemented the page level caching,Even after the user logged in,It's showing the old page content(Links and buttons meant for the Non logged in User).
Caching is obviously good.But how to get rid of this problem ? Do i need to completely remove caching ?
what you want is Partial Page caching:
http://msdn.microsoft.com/en-us/library/ms227429.aspx and http://msdn.microsoft.com/en-us/library/h30h475z.aspx
I ran into the exact same issue and was able to resolve it using Response.WriteSubstitution. Just create a static method that accepts HttpContext as an argument, returns the login status as a string, and render the method using WriteSubstitution:
Response.WriteSubstitution(new HttpResponseSubstitutionCallback(GetLoginStatus));
The rest of the page will cache as normal but the login status will be updated each time the page is loaded.
You can use the VaryByParam directive:
VaryByParam: This attribute allows us
to control how many cached versions of
the page should be created based on
name/value pairs sent through HTTP
POST/GET. The default value is None.
None implies that only one version of
the page is added to the Cache, and
all HTTP GET/POST parameters are
simply ignored. The opposite of the
None value is *. The asterisk implies
that all name/value pairs passed in
are to be used to create cached
versions of the page. The granularity
can be controlled, however, by naming
parameters (multiple parameter names
are separated using semi-colons).
Used like so in the page directive
<%# OutputCache Duration="10800" VaryByParam="State;City" %>
Be careful what you use in the VaryByParam, as this can cause the number of copies of the page in memory to be up to the number of different values of your parameter that exist.
EDIT: as mentioned in comments, this won't work if you're using cookies for login, but some people do use cookie-less login, which puts the info in the GET/POST portion.
See here for more details
on our site we do url rewriting to generate massive amounts of database generated pages. on every page, there is a Login control for users. like this:
Internal aspx page: /DB.aspx?id=123
User visible url: /ABC/123.aspx, /ABC/456.aspx ... (url rewritten)
unfortunately, the tag on each page has an action attribute of "DB.aspx?id=123". when the user clicks the button the browser is posting to /ABC/DB.aspx?id=123 which of course does not exist.
solutions i tried:
1. change the action attribute by subclassing HtmlForm. this destroys the all other forms on the site.
2. remove the action attribute (so that the browser is always posting to the same url). this works on the rewritten pages but on "/" (the default.aspx in the root dir) i get a message that the verb post is not allowed on "/" (iis 6 and i have no control over mappings)
anybody?
Check this really nice blog post from scott gu, http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx.
"Specifically, you can take advantage of the new ASP.NET 2.0 Control Adapter extensibility architecture to customize the rendering of the control, and override its "action" attribute value with a value you provide. This doesn't require you to change any code in your .aspx pages"
Check the section: "Handling ASP.NET PostBacks with URL Rewriting", I have used the adapter he posted successfully.
Ps. be aware there are some issues on asp.net when using url rewrite when using cookieless session, and the rewritten url is deeper than the original page, just like the one you have. (/abc/apage vs. /db?). The issue is right into the source code of the framework, there are workarounds but that's a whole subject (with tradeoffs :( ... you might want to have them at the same level).
Semantics maybe, but does the action attribute = "DB.aspx?id=123" or "/DB.aspx?id=123"? Assuming your URL rewriting allows pass-through to physical pages, this might be your issue.
I never did it, but I saw the code using Reflector and I guess you can fix it this way:
On the page:
this.Form.Action = null;
or:
this.Form.SetAttribute("action", null);
If that doesn't work, just set the path you want:
this.Form.SetAttribute("action", "ABC/123.aspx");
If you upgrade to ASP.NET 3.5 SP1, the action property is now properly recognized and can be set from codebehind.