Develop Reference

Hiding Querystring in ASP.NET 2.0

Our site consists of 3 main pages we call "Start.aspx" and then a content iframe inside of that where the user does nearly all of the site interactions.
Recently though, I've had to implement functionality that will jump between Start.aspx pages in different products and automatically change the content iframe to a specified page.
The actual functionality works just fine, but the issue we're having is that the full querystring is exposed. Because we load all pages in the content iframe, the page URL remains at "Product/Start.aspx" during regular site usage.
However, this new functionality is passing a querystring to Start.aspx (which has appropriate parsers to load the requested page in the content iframe), and we need that URL to remain as "Start.aspx".
So far, I've researched into URL Rewriting, which was throwing errors because the landing page for each product is "[Product]/Start.aspx". I've looked at a different URL Rewriting solution, as well as ScottGu's blog post on routing.
The issue is that these solutions seem to be used for simplifying navigation, such as taking "Blogpost.aspx?Year=2013&Month=07&Day=15" and turning it into "Blogpost.aspx/2013/07/14" which really isn't what we're going for. We're not trying to simplify navigation via URL, we're really just trying to completely hide our querystrings.
What we're going for is turning "[Product]/Start.aspx?frame=Company.aspx?id=1570" into "[Product]/Start.aspx" once the content iframe has what it needs from the initial querystring. We don't need to account for every single page. We just need that to be the overarching rule. 90% of the time it won't be an issue, as most of the work being done doesn't jump from product to product without the user just switching products (which is done in a fashion that specifically uses "Response.Redirect("[Product]/Start.aspx")".
Once the content iframe has loaded from the Querystring paramters, we don't need them anymore for anything. The rest of the functionality runs through the iframe without any issue.
Am I overthinking this, or am I asking for something that's not really feasible?

As far as literally "removing all of the query string characters" and still beg able to pass the querystring values to another page, I do not think that is possible. Unless you do it in a Session Variable or something like that.
IF you're simply worried about sensitive data being displayed in plain text in the query string, there is the option of "encrypting" the query string:
http://www.codeproject.com/Articles/33350/Encrypting-Query-Strings
The query string will still show but it will be "Product/Start.aspx?e0ayfefae0y0someencryptedmess108yfe0ayf0a". The page that receives the query string would decrypt it. So the functionality of the query string is there, but the values are not known to the end user.

Since you've tagged this as an ASP.NET question, I'd say the way to go is to keep navigation data in your Session variables.

Can you use a POST instead of a GET? That way, the data is in the form, rather than the Query String.
As a side note, hiding the parameters as a way of making the URL look nicer and be bookmark-able is fine. If you're doing it for any kind of security reasons, it's very shallow security. It's trivial for a user to see what's being passed in both the form and on the query string and to change and repost those. Security needs to be handled primarily on the server side.

C# Taking the html code of introduction site rather than the actual one, how to skip this?

I have the following problem. My C# application makes use of a webrequest and reades the html code of a url in order to do a bunch of things later on. While everything works fine, there are some websites that when visited they redirect you to another website (http://something.com/disclamer) for example and after you click yes you go back to the original website.
When I run my app it always only checks the html code of the disclaimer page and never gets to the actual page I asked for. I cannot really find a solution at this point since I can't find anything useful in the short html code of the disclaimer site (that comes before the one I want to check).
Any ideas on how I can skip that and take the code for the website I am actually interested in? Please note that I can't find any html redirection code indication (META HTTP-EQUIV etc) in any of the two websites.
Thank you

You can check the StatusCode to decide if you have been redirected. Status codes of 30x will tell you that you've been redirected, in which case you'll need to follow the link in the redirect.
http://msdn.microsoft.com/en-GB/library/system.net.httpwebresponse.statuscode.aspx

I believe you have to analyse the HTML code of such a page with a disclaimer to know which method is used there to make a redirect. Each case can be different: it can be either client-side or server-side redirection. If this disclaimer button submits a form, you will need to make a POST request imitating a button click.

How to make the browser back button take you back through AJAX calls?

I have a page with a lot of dynamically generated check boxes on it. As the users click these check boxes a lot of content on the page changes dynamically via ajax. The end users are complaining that after hitting submit and then hitting the back button to change something, their selections are blown away and they have to do it all over again.
I have seen a few sites (gmail, facebook, etc...) use the hash symbol in the URL to hack the back button so that it performs AJAX calls instead of going back to the previous full page request. I would like to do this to modify the URL before the page submits so that hitting the back button will load their previously selected fields.
For instance:
In Gmail if I am viewing my inbox then my URL looks like this: https://mail.google.com/mail/?shva=1#inbox
Then if I click "Sent Mail" an AJAX call is performed and my URL is modified to look like this: https://mail.google.com/mail/?shva=1#sent
I really like this behavior and want to duplicate it. How is this accomplished?
Do your links actually trigger any javascript or do they just link to the URL with the appropriate hash symbol information?
How do you read in the hash symbol info in javascript?
How does this type of navigation affect search engines? Would a search engine know that two URLS that are the same except for the information after the hash are actually different URLs and index them as such?
What are some other pros and cons of this technique that I should take into consideration?
NOTE: I am using C# with ASP.NET Web Forms and ASP.NET MVC 3.0 in case that matters at all.

To manipulate hashtags, look at location.hash (javascript).
You'll also be interested in the new push/pop state stuff in HTML 5. https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history.
github has done some pretty cool things with this. Check out their blog entry on their tree slider feature at https://github.com/blog/760-the-tree-slider.
There's also the jQuery history plugin at http://tkyk.github.com/jquery-history-plugin/. (EDIT: I see Joe beat me to this one).

take a look at the jquery history plugin http://tkyk.github.com/jquery-history-plugin/ I have used it in the past, and it just might do what you want.

JQuery plugin:
http://tkyk.github.com/jquery-history-plugin/
Another jQuery library that I have used in the past:
jQuery BBQ: Back Button & Query Library
Also, a more scaled down version of the previous if you don't need all it's features and just gives you the hashchange event for all browsers:
jQuery hashchange event
NOTE: Just as a brief intro to the above libraries. The hashchange event is supported natively by newer(HTML5 supported) browsers in which case the scripts will just bind to that event. For older browsers that don't support that event, the script creates a polling loop to simulate the event. In either case you can bind to the event and handle appropriately.
EDIT: To answer your questions:
The links do not trigger javascript, links simply change the url with the hash. The hashchange event monitors this action, and when the hash changes(which is logged in browser history stack) the event fires.
location.hash is used to read the hash value, and any appropriate parsing you would need from that point.
Probably not SEO savvy enough to give you a complete answer on that, but fairly sure search engines DO NOT index hashes.
Pros for this technique is usability as your users will be able to properly use their back buttons. Also any history.back(0) javascript calls will also work properly(i don't like them but people use them). Cons are that as you're initially developing, you can get some quirky bugs depending on how your code is written. All in all though, I think with the use of the plugins much of the legwork has been taken out of the process and it is a great method for usability purposes.

Bookmarkabale ajax calls with MVC routing

I have a page with a menu that uses JQuery AJAX calls to populate the page with. To reflect any changes I update the URL with a #... instead of ?... or /... So an URL that originally reads : htpp://localhost/pages/index/id=1 would look like : http://localhost/#pages/index/id=1. If a user bookmarks this, and later comes back to the page, I wonder if it's possible to use the second URL in my route decoding, or if I have to load it blank, then use the same JS/Ajax to populate the page?
In my mind it is problematic to use Ajax in these cases if a user copies the link and mails it to a friend with JavaScript disabled.
edit#1: Fixed some spelling.
edit#2: To clarify the question a bit: I want a site where I can do the following:
(a): with javascript turned on, use ajax calls to replace the content of a div (without reloading the page)
(b): with javascript turned on, bookmark the page as it is after the ajax call i (a)
(c): take the URL, send it to a person with noscript turned on, and have the same page as after the ajax call was made.
(a) and (b) works just fine on my page but (c) is seemingly impossible.

Currently, the only portion of a URL you can update without causing the browser to redirect is the hash. This portion of the URL is not sent to the server in a request and is only available for client-side processing, so it cannot be used to provide a javascript-free way of providing a link.
The issue you are facing is a common one amongst those using AJAX. The best solution I've encountered is to provide a way to view any AJAX-loaded state of every page through a "true" URL, one that will be passed to the server.
This means you have one URL which provides a "snapshot" of a page's state:
http://localhost/pages/index/1/someaction
And an AJAX-specific URL which provides the local state of the page in the client's browser:
http://localhost/pages/index/1#someaction
What you then have to do is provide some means of generating the "snapshot" link to the page from the AJAX version. A "Link to this Page" or "Permanent Link" button is a reasonable option.

This not possible simply because everything that comes after the # sign (fragment identifier) is never sent to the server and there's no way for the server to ever capture this value, so no routing with it.

You could try replacing the '#' with a '?' This will send the rest of it as a get variable, so you may need to do some tweeks, such as change the format to http://localhost/?pages=index&id=1
There are some fancy things you can set up with the web server so that localhost/article/fancystuff is re-directed to localhost/article.php?title=fancystuff
There are a lot of ways of allowing for an AJAX site to work with bookmarks and the back button. But you should ask your self, do you want people to do certain things. Generally, AJAX is used for more advanced web-applications that do not map well to the traditional back and forth model.
EDIT
What with you additions to the question. I will say that seeming as you want to fully support users who are scared of Javascript that you will need to make your site work perfectly with out any AJAX at all. But you should design it in such a way, that the content of pages are included from separate files. This means that when you add in the additional Javascript, it can load the file and place it more or less directly into the content holder on your page.
You do need to remember that you can't force some one to accept a bookmark or force a change to a book mark. What you are after may be best served suing cookies. Luckily, even less people are scared of cookies, hardly anyone disables them, unless they are either paranoid or up to something.

Use of Response.Redirect in C#

I am working on a website that I inherited (ASP.NET and C#), and I noticed that in almost EVERY method in the code behind of the project pages (except some helper methods), the original author uses Response.Redirect() to redirect to a page (typically home.aspx, but not always).
What is the purpose of doing this? It seems unneeded to me - at least it doesn't appear to change anything the website is doing if I keep it in or remove it.
Thanks.

Response.Redirect() issues a 302 HTTP Redirect header to the browser, which causes the browser to request a new page from your web site.
If the author was using the POST-Redirect-GET pattern to stop the problem with users being able to hit the "refresh" button and repost forms, this might explain why it's used everywhere.

Redirects should really only be used when location is determined by something in the code behind. Redirects tend to cause ThreadAbortExceptions which are just further demand on a system when a simple href might be what the doctor ordered. Unless you can define some true architectural need for redirects, you might just want to begin phasing these things out.

It sends a response to the user agent/browser and tells it to redirect to the specified page. It can be put into any part of the code, but by default, the page will still execute to completion, then the redirect response will be set to the client...
It should only be needed at the last point in the code that you are running (generally)

ASP.NET Pages Post back to themselves, so some use the redirect method to open a new page. Use it when you need it. If you don't see a difference when you remove it. It might be the site uses links to navigate from one page to another, instead of doing it via the server.

Without more information it's hard to be definitive.
However, if home.aspx is an empty page, it may be that the original author may have been trying to terminate the processing of the page early in an effort to prevent subsequent processing.
Normally, Response.Redirect() is used to end the response and inform the browser to navigate to a new page. However, if the browser has that page cached, it may not actually perform a trip to the server. I've seen some cases where developers do this as a way of short-circuiting subsequent processing.
It's also possible that the code is doing something crazy, like making home.aspx the main display page for all data - and using session state or cache to communicate changes across pages. Sadly, I've seen this done too.... sigh. Often this is done to deal with the user being able to multiply submit forms.