We are using the Response.Redirect to send users to a web site to take a questionnaire. We have a database that stores information about the user's eligibility to take a survey and if they are eligible, a 'Take Survey' button appears on their home page and a variable stores the URL for the Survey.
On the TakeSurvey_Click event, the code originally the following:
FormsAuthentication.SignOut();
Response.Redirect(TheURL);
Pretty straight forward and worked great for years. Recently, we have changed the web site to which the user was being redirected. There have been no issues for many thousands of users; however, for a reasonably significant group (2-3%), nothing happens when they press the 'Take Survey' button.
I am reasonably certain after searching the internet, that I have tried all of the recommended methods for handling this situation, but none really does what I want. What I would like to happen is, that if the Take Survey doesn't send the user to the link (BTW, we have checked the link being generated for the non-working links, and they are good links), I want an informational page to appear telling them that we are having issues and if they could send us some information about their environment, it would be useful in fixing the issue. Seems simple enough, but no matter what I try, I either can't get the page to not display, or, if I use the override and send a false, it never displays and never redirects.
Anyone have any ideas?
Response.Redirect sends a "302 Moved" response to the browser. The browser is responsible for navigating to the destination URL.
Thus, once you've issued the Response.Redirect, it's out of your hands and there is no easy way to detect that the browser has not successfully navigated to your chosen URL.
Now, there are a few different ways (that I can think of do deal with this):
You might be able to set document.location from client-side JavaScript.
The page that issues the redirect could refresh itself periodically (using JavaScript or meta refresh). If it finds itself still on the same page after it should have gone somewhere else, then it can issue a warning.
Or, more simply, the page that issues the redirect could just have instructions stating "We're sending you to take the survey. If, after 30 seconds, you're still looking at this message, something went wrong.".
Related
I have a website that sells products and I'm using google analytics to know some statistics about the website. Sometimes, errors happens for various reasons and purchases doesn't go through. You then have to refresh the page and try again, then everything works. The website displays the message telling the user to refresh and try again. I'm curious how many people actually do that. My question is, is it possible to know what users do when this error happens? Do they refresh and try again? Do they close the tab or do they do something else?
The question is quite broad at this moment, but there are a couple of improvements to your measurement setup, that can help you to investigate this customer behavior.
What I would do, is to implement an event tracking to indicate, that this error has occurred. You can find details about event tracking in this guide. Although I suppose, that your users are not likely to enter the website at this page, it might be a good practice to set the non-interaction flag of the event, as it is not actually generated by a user interaction.
I'd also create tracking for page reload, either by creating an other event for this, or by adding -reload suffix to these repeated pageview URLs. You can find good resources for this on SO as well, e.g. this one.
If you have a special URL for this error page (e.g. purchase-error.html instead of purchase-success.html), it is also easy to track the exit rate specific to this page.
Besides of Google Analytics, you might also want to set up heatmap or screen recording tools to understand this behavior. Hotjar, Lucky Orange are a few examples. (No affiliation.)
I have a task to list all pages which are opened at that moment and show how many people are on that page.
I am looking for a way to make that happen without keeping any db records or saving information on a text file or smth like that. (Not seccessarily, then. Of course I am going to save that info to a dB, I just wanted to the logic of catching opened page addresses.)
I can of course keep track of every page which are opened till that time, but I want the page address appear on the page when someone opens that address and disappear when user is no longer browsing that address.
Can you give me some ideas how to make that happen using ASP.NET?
Note: I am using web forms with asp.net 4.5
Thanks!
"I just wanted to the logic of catching opened page addresses"
Use javascript in a timed loop (onload and then every 30 seconds perhaps) on every page, to asynchronously post to a page on your server. It should send information identifying the page. This will give you a good idea of how many people currently are on this page.
Store this information in a db in your code-behind, and use this information to report as you wish.
Of course if a user leaves their browser open on one of these pages or opens another tab it will still be reporting as 'open'.
To get the current url in javascript you can use:
var pathname = window.location.pathname;
In google analytics you can see what pages are being used in near-real time.
Why not use that to solve this issue - it's easy to setup.
Currently reading Bloch's Effective Java (2nd Edition) and he makes a point to state, in bold, that overusing POSTs in web applications is inherently bad. Unfortunately, he doesn't specify why.
This startled me, because when I do any web development, all I ever use are POSTs! I have always steered clear of GETs for security reasons and because it felt more professional (long, unsightly URLs always bother me for some reason).
Are there performance differentials between GET and POST? Can anyone elaborate on why overusing POSTs is bad, and why? My understanding - and preliminary searches - seem to all indicate that these two are handles very similarly by the web server. Thanks in advance!
You should use HTTP as it's supposed to be used.
GET should be used for idempotent, read queries (i.e. view an item, search for a product, etc.).
POST should be used for create, delete or update requests (i.e. delete an item, update a profile, etc.)
GET allows refreshing the page, bookmark it, send the URL to someone. POST doesn't allow that. A useful pattern is post/redirect/get (AKA redirect after post).
Note that, except for long search forms, GET URLs should be short. They should usually look like http://www.foo.com/app/product/view?productId=1245, or even http://www.foo.com/app/product/view/1245
You should almost always use GET when requesting content. Only use POST when you are either:
Transmitting sensitive information which should not appear in the URL bar, or
Changing the state on the server (adding/changing/deleting stuff, altough recently some web applications use POST to change, PUT to add and DELETE to delete.)
Here's the difference: If you want to give the link to the page to a friend, or save it somewhere, or even only add it to your bookmarks, you need the full URL of the page. Just like your address bar should say http://stackoverflow.com/questions/7810876/abusing-http-post at the moment. You can Ctrl-C that. You can save that. Enter that link again, you're back at this page.
Now when you use any action other than GET, there is simply no URL to copy. It's like your browser would say you are at http://stackoverflow.com/question. You can't copy that. You can't bookmark that. Besides, if you would try to reload this page, your browser would ask you whether you want to send the data again, which is rather confusing for the non-tech-savy users of your page. And annoying for the entire rest.
However, you should use POST/PUT when transferring data. URL's can only be so long. You can't transmit an entire blog post in an URL. Also, if you reload such a page, You'll almost certainly double-post, because the above described message does not appear.
GET and POST are very different. Choose the right one for the job.
If you are using POST for security reasons, I might drop a mention of other security factors here. You need to ensure that you send the data from a form submit in encrypted form even if you are using POST.
As for the difference between GET and POST, it is as simple as GET is used to send a GET request. So, you would want to get data from a page and act upon it and that is the end of everything.
POST on the other hand, is used to POST data to the application. I am talking about transactions here (complete create, update or delete operations).
If you have a sensitive application that takes, say and ID to delete a user. You would not want to use GET for it because in that case, a witty user may raise mayhem simply changing the ID at the end of the URL and deleting all random uses.
POST allows more data and can be hacked to send streams of files as well. GET has a limited size though.
There is hardly any tradeoff in using GET or POST.
I notice on some sites i can login wrong which brings me to a login page. log in incorrectly again which brings me to a wrong password page (where i can log in) and if i login wrong again i dont increase my page history count. It takes exactly 2 backs no matter how many times i get it wrong and i dont see any pages in my forward history
How do i do that? ASP.NET
Take a look at this:
Server.Transfer Vs. Response.Redirect
Basically, if you want to do it without the user (browser) knowing about it, you use Server.Transfer; otherwise you do a Response.Redirect.
Also note, although not in server side code, there is a possibility the site uses Javascript like location.replace() - this way the history does not change.
You dont. As long as the login url stays the same there wont be another page added to the history. There may be parameters after the ? that changes the url or possibly POST data.
A site has 100's of pages, following a certain sitemap. A user can navigate to page2.aspx from page1.aspx. But if the user goes to page2.aspx directly say through a book marked URL, the user should be redirected to page1.aspx.
Edit: I dont want to go in and add code to every page that needs to fulfill this need.
Note: This is not a cross-page postback scenario.
You might consider something that is based off WorkFlow, such as this: http://blogs.msdn.com/mwinkle/archive/2007/06/07/introducing-the-pageflow-sample.aspx
The WCSF team also included a pageflow application block that you can use as a standalone add-on to your application.
I guess you could check the referrer, and if there isn't one / or it isn't page1.aspx then you could redirect back to page1.aspx.
As another answerer mentioned, you could use the Referrer header, but that can be faked by the client.
Since you don't want to modify each page, you could do something with an IHttpModule. Assuming you have some way of describing the valid page navigations, you could do something like this in the BeginRequest handler:
Check the session for a list of valid pages (using a default list for first visit if none are in the session).
If this request is for an invalid page, redirect to the place the user should be.
Based on this request, set up the list of valid pages and redirect page in the session so it's ready for the next request.
I recently worked with real code that checked to see if referrer was blank and used that as a step in authorization. The idea was users wouldn't be able to fake a referrer, you don't need a custom browser to fake a referrer. Users can book mark your page to delicious, then delicious.com is the referrer (and not blank).
I've had real arguments about how sophisticated a user needs to be to do certain hacks-- i.e. if users don't know how to set the referrer, then you can trust it. While true, it's unlikely your users will write a custom browser, but there already are Firefox addons to set headers, referrers etc and they're easy to use.
Josh has the best answer-- on page2 you should check the page hit log and see if the user has recently visted page1
I like alot of the answers above (specifically the workflow).
Another option, is creating each page as a usercontrol and having page1.aspx control what usercontrol gets loaded. This has the advantage of storing your workflow in a single place instead of on each page.
However, I don't think there's a magic bullet out there. It sounds like this security problem is an afterthought, or possibly reported as a bug, and you have been tasked with fixing it quickly and efficiently.
I would start weighing the answers here with their associated cost in hours.. I suspect the quickest solution will be to check referrer addresses on each page. Although hackable, it is obscure and if that risk is acceptable to you it may be the appropriate solution.