We have a sales flow that at a certain point redirects the user to an external secure page.
This is done calling an internal page with some logic to prepares the request for the external page and then submits the data.
When the user is in the external page, if he clicks the back button will go to our "dummy" page only to be redirected again to the external page.
The user should quickly click twice to get to the correct page.
Is there any way to avoid that? Like not adding the "dummy" page to the history?
I cannot change the external page.
I have read about window.location.replace but in this case I am submitting a form, not redirecting the page.
I'm a bit late to this but you could attach a history.pushState() to the onSubmit event on the interim page which injects the previous page in front.
So where your original flow was
Startpage (S) -> Interim page (I) -> External page (E)
The history version would be
S -> I -> S* -> E
Where S* is the url of S which has been inserted with pushState()
Obviously the better option would be to not have the interim page - maybe it would be better spending the effort on setting up S to do everything you need it to?
Related
I have a form that when submitted it goes to a different "success page" and I want to use that landing page to track conversions or count how many times people hit the "submit". I could use a page view tag but then that will fire every time someone goes to that page. So perhaps if someone hits the back button and reloads the page then that will count as a form submit.
So I would like to make a page view Tag in google tag manager that only fires if the page view is coming from a specific URL or referred from a specific URL. Is this possible?
Thanks in advance.
It is possible. Enable the built-in "referrer" variable, and on your target page create a trigger "pageview", with an added condition "referrer equals <your referrer>".
Some browsers might not send a referrer header, so this is not 100% reliable. If the page that sends the traffic is under your control, you might consider using a tracking parameter instead.
I'm trying to create page view tags. I have to create two for two different triggers.
Page view triggered by history change;
Page view triggered on window load (because first page load doesn't have any history change)
My problem is the home page, which is firing both tags.
Because if put in URL www.mysite.com, the page redirects to my.site.com/home
which creates a window load and a history change. So two page view tags are fired.
I can't exclude historychange trigger to exclude page path: /home because once people got into the site they'll navigate back and forth.
I can't exclude windowload because people may use either URL to enter the site (mysite.com or mystie.com/home)
Anyone can help me with this?
I suggest to create 1 page view tag instead of 2 and use both triggers. Multiple triggers in GTM tag work with OR operator. And set tag to fire once per page.
Advanced settings -> Tag firing options -> Once per page
UPD I'm afraid that in this case other hits for virtual pages triggered by History change will not be fired (because of 1 per page rule). Try to check what value have variable Old History Change after redirection. If undefined or empty, you can use it in trigger of History Change tag as exclusion.
...in comparison to requests of normal link click behaviour. I thought I might be able to use this to throw away some cached stuff on the serverside. For a more technical orientated target audience this could be a relative natural way of clearing a cache for i.e. graphs and charts.
To be clear - I am using ASP.NET MVC
I've just checked the three browsers you're likely to care about, and all three add extra cache headers in the request when you refresh the page. Conceivable you could check for those headers to throw out some server-side cache. It also seems a logical and natural way to do it.
IE: adds "Pragma: no-cache"
Chrome: adds "Cache-Control: max-age=0" and "If-Modified-Since: Tue, 17 Dec 2013 10:16:22 GMT" (disclaimer: time may vary)
Firefox: adds "Cache-Control: max-age=0"
I just checked this by refreshing this page in all three browsers, and checking Fiddler. It is possible there is more sophisticated logic going on that I haven't caught on to.
Since it's in MVC, I would use the TempData to achieve this. On the first load of your method, you can set a value in the TempData so on the next load(the refresh) you would have a value set in this.
Let say you have a Add method, I think that should do the trick :
public virtual ActionResult Add(Model model)
{
if(TempData.ContainsKey("yourKey"))
{
//it means that you reload this method or you click on the link
//be sure to use unique key by request since TempData is use for the next request
}
TempData.Add("yourKey", true);
return View(model);
}
Add this script to your head section:
<script>
$(window).keydown(function (e) {
if (e.which == 116) {
e.preventDefault();
var l = window.location;
var lp = (l + "?").split('?');
window.location = lp[0] + "?f5=1&" + lp[1];
return false;
}
});
</script>
In server side just check if Request["f5"]=="1"
If you prefer not to modify the URL, you may add a temporary cookie. something like this:
<script>
$(window).keydown(function (e) {
if (e.which == 116) {
AddCookie("F5","1")
}
});
</script>
On page load check if the cookie exists and delete it for next request.
You could compare the current session ID to the last page that was loaded and then compare the IsPostBack command.
If IsPostBack is true you know the user has clicked something on that page to post the page back.
If the last page that was retrieved for the current session ID was not the same as the page you are currently loading then they arrived at this page from another page.
If the last page that was retrieved is the same for the current session ID as the current page you are processing then this was likely a refresh (F5).
The only problem would be that you would detect F5 the same as someone putting their cursor in the address bar and hitting the Enter key once the page had finished loading, but I doubt this would be a problem for you.
EDIT:
There seems to be some confusion on the comments about how this system would work so let me explain further. As was pointed out to me IsPostBack is not available in MVC so you have to test for post backs as shown here:
ASP.NET MVC - Is IsPostBack still here?
Let us consider the three ways in which you can end up at a page, any page. For our examples let us assume we want to detect refreshes on page X.
You can get to Page X these ways:
1. User presses a button on page A which takes you to page X.
2. User presses a button on Page B which posts you back to page B (post back).
3. User presses F5 or reloads the page some other way. - this is the one we want to detect..
There is scenario 4 which is 'user comes to page X from another site' but this would start a new session so let us not consider this.
Everytime a user loads a page you store that page somewhere along with the SessionID. The SessionID is constant for any one user for the duration of the session time out. There are some caveats to this such as accessing from different browsers on a single machine but I do not want to confuse matters.
Scenario 1:
User loads page A, we look in our memory and there are no records at present. We store 'Page A' and the sessionID in memory.
User clicks button on Page A.
User is redirected, posts or transferred to Page B.
Page B loads, we check the 'IsPostBack' flag, it may or may not be true at this point. If it is we know it is not a refresh, if it is false we need to continue to test as follows. we look in our memory and there is a record for 'Page A' for the current Session ID (remember the session ID does not change between requests for any given user).
because the previous page was 'Page A' and we are on Page B we know this is NOT a refresh.
We store 'Page B; and the sessionID in memory (in practice we either erase or update the previous record pointing to Page A).
Scenario 2:
User loads page B, we store 'Page B' and the sessionID in memory.
User clicks a button on page B.
Page B loads, we check 'IsPostBack' flag. It is true so we know this is not a refresh.
Scenario 3:
User loads Page B, we store 'Page B' and the sessionID in memory.
User refreshes the page or reloads it by putting their cursor in the address bar and hitting enter.
Page B loads, we check the 'IsPostBack' flag, it is false so we need to continue to test as follows. we look in our memory and there is a record for 'Page B' for the current Session ID. Because the previous page was 'Page B' and we are on Page B we know this IS a refresh.
By using this approach you can detect refreshes. If you are using MVC you can test Request.HttpMethod=="POST"
The only problem you get is if the user does a POST, you do a redirection, then the user goes back one page and refreshes from there are is will resubmit the form, sending the POST again. This will be detected as a fresh submission when it is actually a refresh. This can be eliminated using a Nonce approach or something similar.
Move backward through history skipping the same page with different query string
The above is similar to my question, but I'll be more specific as mine concerns POSTs:
Scenario:
User is on Product Listing page. (Shorts.aspx)
User picks a product and navigates to product detail page (Best-Cargo-Shorts.aspx)
User clicks add to cart which performs postback (POST) of form to same page. (Best-Cargo-Shorts.aspx) -- this now shows Details page again, but with an Added TO Cart message at the top.
Current Behavior:
After the Add TO Cart form post; when the user clicks the Back button they navigate back to the "pre-post" version of the same page.
Desire:
When a user clicks the BACK button, I'd like it to go to Shorts.aspx, NOT Best-Cargo-Shorts.aspx, effectively Skipping the "pre-POST" page, or more accurately NOT STORING the 2nd POSTed page (Best-Cargo-Shorts.aspx).
Furthermore, I always want to avoid that "Page Content Expired" message. I just never want the POSTed version of the page in history. In this way, the following could also be true.
Shorts.aspx > Best-Cargo-Shorts.aspx > Best-Cargo-Shorts.aspx [POST] > Cart.aspx
If on cart and BACK button is pressed, I want the browser to navigate to Best-Cargo-Shorts.aspx (without the POST).
Is this possible with C#? Furthermore, is there a non-javascript solution?
Thanks.
One common way of handling this is the Post-Redirect-Get pattern.
In essence, the target of a POST request always responds with a 303 See Other (if HTTP 1.1) or 302 Moved Temporarily (if HTTP 1.0) status code redirecting the request as a GET, and usually eliminating the expired POST page from history. Potential downsides include the form parameters possibly remaining attached to the GET as a query string, and I've no clue how well it would (or wouldn't) integrate with ASP.Net Forms, MVC, or other web frameworks.
Generally, you should be using the post-redirect-get pattern, i.e. after the user adds the item to the card using POST, redirect him to Best-Cargo-Shorts.aspx with 302.
Now to your question, I would use Ajax for the post. I cannot think of a cross-browser way to achieve the desired behaviour using only server side code.
I have a set of interlinked dynamic web pages.
When the user clicks from one page to another, I don't want any caching to happen - the request must go to the server, which will return an up-to-date page.
But when user clicks Back, I do want the cache to be used - some of the pages can take some time to generate, which is fine when you're clicking through to them, but not when you're clicking Back.
Is this possible?
(Please don't suggest re-engineering everything as a single page making AJAX queries!)
(Note: this question is the opposite of the ever-popular "How do I prevent caching when the user clicks Back?" question.)
A common trick for avoiding the browser cache when dealing with dynamic pages is to add a parameter to the link url that is unique (using the time, to the millisecond is common).
When the user hits the 'back' button, they will go back to the last rendered version, and should get it from the cache.