I have a shopping cart page where my 'Pay By Credit Card' button fires a popup:
window.showModalDialog(ccPaymentURL, null, "dialogwidth: 450px; dialogheight: 370px; center: yes; resizable: yes");
The URL loaded into this popup (an SSL page that sits in a different domain) collects the CC info, processes the charges and (via a webservice running on the orginal site) marks the order as 'Paid'.
At this point, the popup is supposed to refresh the parent - letting the parent requery the db and find that the order's been paid and re-display the updated order status.
My integration tests show everything working correctly. But in reality...some users are breaking the chain somewhere and the parent page is failing to reload. I suspect it has to do with how different browsers (and/or browser settings) treat showModalDialog so i'm looking for an overview of known things that can go wrong when trying to implement this sort of use case.
thx
Could there be some sort of cross-domain security policy that's preventing the complete chain from happening?
Or how's the error handling from within your pop-up? Does it handle every case for what happens if the verification occurred successfully or not?
Related
The question is probably easily misunderstood, so I'll go into more detail:
I am trying to automate a task in a certain (very outdated) browser-based idle game that is written in PHP in order to polish my portfolio with a little more variated projects.
I used DevTools to reverse most of the requests and wrote a small C# Request wrapper to test them. I can get most of the actions I want to work, using the respective ajax get requests and the correct cookies/headers - not really part of the problem.
Example:
Attacking an enemy:
https://somebrowsergame.com/game/ajax.php?mod=location&submod=attack&location=3&stage=2&premium=0&sh=****mysessionhash****
Making a GET request to this URI with the correct headers and cookies, I can perform the in-game action programmatically and successfully from my C# console application and see that the fight has taken place when visiting the site in the browser.
The problem:
When monitoring all requests after clicking the "attack" button, via DevTools, even with preserve logs enabled, I don't see any redirects or way of determining how my browser gets told where to navigate to.
Findings
I found out that the button calls a javascript function attack() in its onClick event and tried debugging the javascript in DevTools in order to find out where somethign happens (such as setting document.href or smth), but when Debugging I ran into a seemingly infinite loop of setInterval handler and setTimeout handler in the call stack.
I also cleared the Network tab after the onClick event (and after the ajax request which I could find during Debugging) but the only request/response I got was the document GET request for the final page, no request telling my browser which site to navigate to.
Monitoring requests
The request made to initiate the action (via button click on website or ajax GET request as outlined above)
The document response / site navigated to
What I want to know is how my browser got told which site to navigate too, as the request URI for the document request (getting the html of the target page) has a parameter generated on the server side (logId)
I have also used "All" request types in DevTools, as well as negative filters when monitoring requests but never was I able to see how my browser knows which page to navigate to. I tried with source breakpoints at "beforeunload", tried inspecting the javascript source connected to the onclick event of the button (which didnt give me anything, as the js is minified and barely readable - i am not even sure if the navigation is done via window.target.href) and googled this question in all possible wordings which lead me nowhere
I am not too versed in web development, but I am sure my browser has to be told where to navigate to in some fashion after clicking that button?
I'm setting up a set of custom templates for a SagePay server integration (iFrame), and I'm wondering if anyone knows if it's possible to prevent the confirmation page (card_confirmation.xslt) being presented to the user.
It mostly duplicates information presents to customers earlier on in the checkout process and so is largely redundant.
So it's a bit of a long shot but can we by modifying some form value in one of the other templates or by any other method tell the system to skip that page?
Thanks.
You won't get this confirmation page if you pass Profile=LOW with the original transaction registration post. In fact, if you are not sending this and displaying the Sage Pay screens in an iframe, you are going to have problems with some browsers.
I'm currently trying to integrate Econda tracking in the one page checkout process of a magento webshop with the special requirement that the tracking which is normaly done on the thank-you-page already is done once the customer clicks the place-order-button (between button click and redirect to payment provider or thank-you-page). The tracking code itself is dynamically created by an magento extension and injected as html into the phtml file of the thank-you-page. By loading that phtml the information is sent. Also the order in magento must exists before the tracking code can be injected (means place order button must already be clicked).
Currently I'm trying to create an "invisible" phtml, which is loaded once the customer clicks place-order-button and which contains the tracking code. This page should be shown for some seconds and then forward/redirect to either the payment provider or the thank-you-page. This is where I'm totally lost.
I have an observer on the event that is fired once the order is complete/saved. This observer calls an action within my model. But the model can not load/show a phtml.
How can I load a custom phtml-file once the customer clicks the place-order-button, show this phtml for some seconds, and then dynamically forward to either payment provider or thank-you-page?
The Cart Success page, by its very nature is the place that you should be putting any e-commerce tracking Javascript or markup.
It's the very first thing to be delivered to the browser once all the necessary order processing has gone on in the back end. Delivering them to an interim page for only a few seconds seems cumbersome and ultimately inefficient. It's possible, but it's bad practice.
Do you have any particular reason why the success page is insufficient? I can't seem to find that in your question.
Loading a new block into your success page is an easy process. Learn some more about Layouts and Templates (Maybe try Alan Storm's tutorial here) and use this method.
There would be two more options:
You could add your tracking to the on click event of your button
You could use server side tracking using the econda PHP SDK
Here's how you can add tracking to click events
<script type="text/javascript">
function trackIt() {
window.emosPropertiesEvent({
siteid: "my-site.de",
content: "CONTENT-LABEL"
});
}
</script>
<tag onclick="trackIt();">content</tag>
Be careful using click event tracking in links, it will not work if your page unloads before the tracking event was send.
I could not find the english version of the econda PHP SDK documentation, so sorry, here are the German docs: https://support.econda.de/display/INDE/PHP-Helferklasse
As already mentioned, your thank-you page is the best place to add tracking. An additional reason is, that normally you want to track if a customer really ordered or not. Payment pages are common problems, so it makes no sense to add "order successful" tracking calls before.
I'm working on a web application developed classic asp. It has logout button on the top menu which basically does the following actions
Session.Abandon()
Redirect to Index.asp, where users can login again.
After logging off users return to index.asp. But if users click back button the browser, they go to previous page. I don't want this to happen. I want a message saying that they are already logged off.I have implemented following steps
1.Add Response.Expires=-1 and Response.CacheControl="no-cache" at the top of each page.
2.On each page i'm checking session object to see it is not empty. If empty i'm creating a message saying that they are already logged off and need to log in again.
Now when users click back button after logging off, instead off showing logged out message, i get "Web page expired" message on IE8. I see the same behavior when users click back button on some page while logged in.
Any ideas how i can implement this better.
Thanks.
You can't stop users pressing back. A common scenario to work around this is that POSTs target a server page that displays no output but redirects to a new location instead (where the results can be seen).
There are additional non caching declarations that sometimes help:
Response.Expires = 0
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
I did read some time ago (hence inability to find link) that setting an expires to -1 can cause some browser to ignore it rather than have it expire immediately.
Even adding these extra cache controls won't stop some browsers from caching some things some of the time. FF quite often ignores a forced cache reload by the user, so you are in the browser makes hands to a certain extent.
Regarding your "Web page expired" message, this is (as mentioned) the result of the browser trying to stop you from resubmitting POST data (and potentially duplicating what you last did). The best way to get around this, and solve a number of other common UI issues on forms is to POST back to the same page, then if/when the action is completed, using a response.redirect to the same page, maybe with a URL encoded message to say "all done successfully". This allows your users to refresh and helps with the back button issue as most browsers now don't store properly redirected pages in their history.
I am implementing a web application using ASP .Net and C#. One of the pages has a requirement that it always needs to be fetched from the server, rather than from the local browser cache. I have been able to achieve this.
We have a back button in the application, which simply invokes javascript:history.back() method. The problem is that when the back button is clicked to navigate to the page which is always to be reloaded from the server, the browser displays a "Web page expired message".
The intent here is to force the browser to reload the page rather than display the web page expired message.
Any help would be highly appreciated. Thanks a ton in advance.
You will probably need to change the implementation to make the browser load the URL explicitly:
window.location.href = 'http://....';
instead of invoking the back button, since the intention of the back button is to get the last page from the cache.
(If browsers would not act that way, they would re-send your form data multiple times when using the back button during a registration process or similar.)
You mean you want to control browser behaviour, which is not possible. I doubt you can solve it that way. You could set the expiration time to a small value (1 minute perhaps?) so that the page is still valid if one navigates back quickly.