We are facing StalePageException very frequently. I tried debugging on locally by adding debug point in getStoredPage() method just before this code and then i tried another request for same flow . The render count is not updated but on production i could see this issue.
Can any one help what is causing this and how can i reproduce .
if (renderCount != null && pageInstance.getRenderCount() != renderCount)
{
throw new StalePageException(pageInstance);
}
StalePageException is usually being thrown when the user opens several browser tabs/windows for the same page instance, for example by copy/pasting the current url from the address bar. Then making some more requests in one of the tabs and then trying to use one of the other tabs.
Wicket makes this check so that the user do not use a stale page instance. Imagine a page that shows the details of some entity. If the user deletes this entity in tab1 then (s)he should not be able to edit the same entity in another tab.
I am using OWASP to prevent information leakage on my application. But this not working properly as expected.
I logged in to my application and done some random clicks on the tabs in the application. Then I cleared the web browser history and cookies .When I click on any tab after this I will get an pop up screen by saying the session got expired please login again and it redirects me to the login screen when I click on the “ok” button (Till this it worked fine ) . But when I login again and clicking on the tab that used in the last session after deleting the cookies, I get the error “cross-site request forgery (CSRF) attack ...” (this is something weird). If am Clicking on any other tabs I am not getting any error and it works fine
this is a snippet of my OWASP.properties file :-
#org.owasp.csrfguard.action.Empty=org.owasp.csrfguard.action.Empty
org.owasp.csrfguard.action.Log=org.owasp.csrfguard.action.Log
org.owasp.csrfguard.action.Log.Message=potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, uri:%request_uri%, error:%exception_message%)
#org.owasp.csrfguard.action.Invalidate=org.owasp.csrfguard.action.Invalidate
org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect
org.owasp.csrfguard.action.Redirect.Page=/ourUI/csrfError.jsp
#org.owasp.csrfguard.action.Redirect.Page=/OLDUI/error/error.jsp
#org.owasp.csrfguard.action.RequestAttribute=org.owasp.csrfguard.action.RequestAttribute
#org.owasp.csrfguard.action.RequestAttribute.AttributeName=errMsg
org.owasp.csrfguard.action.Rotate=org.owasp.csrfguard.action.Rotate
#org.owasp.csrfguard.action.SessionAttribute=org.owasp.csrfguard.action.SessionAttribute
#org.owasp.csrfguard.action.SessionAttribute.AttributeName=Owasp_CsrfGuard_Exception_Key
I have uncommented the following line and checked
org.owasp.csrfguard.action.Invalidate=org.owasp.csrfguard.action.Invalidate
This time I got the error when I click first time on the tab which I have used in last session (followed the same procedure as above) Second time onwards it worked fine. Can anyone please help to find why this error I am getting? Do I need to make any other changes on this file?
Recently, Facebook has updated the component "request dialog" assigning responsibility to the exclusion of requests to the developers (http://developers.facebook.com/docs/reference/dialogs/requests#deleting). He also made other adjustments to the format of the request id. Thus added configuration option "request 2.0 efficient" on menu of the application developer.
The problem started after this change , the component "request dialog Multi - Friend- Selector" is in serious trouble. The component is crashed while trying to load friends. Sometimes friends loads, but the component does not resize height.
See the image of the errors:
Crashed before load friends:
http://postimage.org/image/glk2mf3bb/
Resize fail
http://postimage.org/image/iobduhn41/
In chrome browser component generates the following error:
s-static.ak.facebook.com/rsrc.php/v1/yS/r/syXGEAW5WYH.js:36 Uncaught TypeError: Cannot read property 'origin' of undefined
In firefox generates following error:
Erro: Permission denied to access property 'DocRPC'Arquivo-fonte: https://s-static.ak.facebook.com/rsrc.php/v1/yS/r/syXGEAW5WYH.js Linha: 36
Can you reproduce the error with the code itself Documentation
http://developers.facebook.com/docs/reference/dialogs/requests
Help please.
Seeing same errors here, but I can add some info:
It does seem to work if you use the basic example in https://developers.facebook.com/docs/reference/dialogs/requests, which opens up the dialog in a new browser window.
In Chrome, I found an additional error message to the one you posted:
"Unsafe JavaScript attempt to access frame with URL [...] from frame with URL [...]facebook.com/dialog/apprequests. Domains, protocols and ports must match."
From all that I guess the error may be related to the dialog display mode (read https://developers.facebook.com/docs/reference/dialogs). Within my app, I am getting this error exactly as you do, unless I set display to something like 'popup', in which case everything works (but a new borwser window is opened). The docs do state that "Because of the risk of clickjacking, [iframe] is only allowed for some certain dialogs, and requires you to pass a valid access_token." Well, passing access tokens did no good for me.
Little question: are you using some toolkit like GWT?
I am adding Facebook login to my existing asp.net application. I have added a Facebook login button to my login screen. Now, I click Facebook's login button and in IE 9 it throws client-side exception in all.js on Line 22: if(a.params)b.fbCallID=a.id;
Even after that exception I see the Facebook login screen and can log in, and in the main browser window I get the auth.login event, so I can live with that.
But, if I am already logged in to Facebook, I come to the page and click Facebook login button, I briefly see the empty popup window, then I get teh same client-side exception, and then I get no event in the main browser window, so I don't know if the user logged in so I can't redirect them to another page.
I tried the channelUrl trick but it didn't help.
Any suggestions what's going on?
I found this hack that fixed the issue for me; add this line right after you call FB.init():
// Hack to fix http://bugs.developers.facebook.net/show_bug.cgi?id=20168 for IE7/8/9
FB.UIServer.setLoadedNode = function (a, b) {
FB.UIServer._loadedNodes[a.id] = b;
};
The reason it is happening (from the websites and documents I have read, and believe me, I've read a LOT) is that IE refuses cross-site javascript, and it sees the all.js as crossing the sandbox border. A good discussion can be found here.
Some people say that adding the channel.html file works, but we have tried all flavors of that, and have not had any success. (Remember that the http or https must match the page sending the request.)
Microsoft makes reference to this same issue and their advice is to add the site to trusted sites (that doesn't help). Old advice (from last year) is to add CP="HONK" as your compact privacy policy, but I think that bug was fixed, and it was cookie-related.
What seems to be happening to us is that the login actually continues, and the callback gets called properly, but the main thread that should complete outside of the login call stops executing (because of the error). So, any functions outside the login fail to execute after the login call.
If anyone has a way to get IE to not throw the exception or to create a workaround for this issue, I am desperate to have it. Any info needed I will be happy to provide, but a sample is here:
enter code here
code before login here...
FB.login(function(response){
callback stuff here... This part fires.
});
main thread stuff here... This fails because of permission denied error.
My Magento Verison is - 1.4.1.1
I am having two problems:
1) When I am going through various steps of Onepage checkout (registration, billing, shipping, and payment tabs), sometimes during this process I am redirected to the cart page. There is no error, no exception, no report gets generated in var/report. I dont know how to debug it. Aren’t there any logs I can look for?
2) In same Onepage Checkout process after clicking on place the order (last step) , some times it redirects to the cart page, sends an email saying that the order failed with the message:
Quote totals must be collected before this operation.
To resolve it I commented this line in prepareRecurringPaymentProfiles in the file magento/app/code/core/Mage/Sales/Model/Quote.php, which solved the problem:
throw new Exception("Quote totals must be collected before this operation.");
I dont know if these 2 problems are related or not. But I am not having the 2nd problem now but having 1st one quite frequent. What could be the reason and how to resolve it?
further update-I checked the firebug trace, It is 500 internal server error which comes sometimes in any of the step in one page checkout. I was able to dig down into savebillingaction, saveshippingaction functions in onepagecontroller.php and found that error comes when $this->getRequest()->isPost() is blank , If it is 1 then it goes ahead, and goes to the next step else it redirects to cart, No I dont know why this is not 1 or is it because ajax is not able to send post data but I checked XHR request, Ajax send the post data every time (checked with firebug extension). Can Someone tell me What I could do next to troubleshoot. Where I can look for these Ajax Calls?
Shipping.phtml (any step.phtml) has JS at the bottom , How does it call OnePagecontroller saveshippingaction function ?
Since it's internal server error, try to access the error log of the server. Will tell you where is the problem. I' ve had the same problem in 1.7.0. In my example the problem was at /app/code/core/Mage/Usa/Model/Shipping/Carrier/Fedex.php
For anyone else coming across the "Quote totals must be collected before this operation." error, check your Apache logs for the reason of the 500 internal server error. If it's something like this:
mod_fcgid: read data timeout in 40 seconds
Premature end of script headers: index.php
process 26126 graceful kill fail, sending SIGKILL
..PHP is taking too long to respond. Usually its the onepage/checkout saveOrder action because it's quite heavy and often needs to connect to third party services (payment gateways, newsletter services like mailchimp, etc.). These calls to third party services can take a while, depending on the network state and might be the reason of PHP timing out.
You can start by increasing the timeout, but it's not a good permanent solution because you want to find out why this is happening in the first place.
New Relic is a good tool to monitor these calls (and a good tool to monitor your Magento store in general).
Firstly, commenting an error message is almost never the way to solve a problem, as you are just covering up some issue that may have severe consequences for your system.
Nailing down errors like this can be hard, but there are a few places to look first:
Did you install this system on a lower version and then upgrade? If so, how?
Are you using any extensions that modify the sales/checkout portion of the site?
Have you overridden any of the models concerned with this part of the site?
Have you changed the JS or HTML for the checkout?
If one of those is the case, you should review those changes for bugs. If not, try turning on the default theme for the site and checking out again. If the bug disappears, there is a problem with the theme that you are using. If it still appears, the problem is in code.
In that latter case, use Firebug to verify that the offending page requests result in Magento sending back "redirect" commands to the frontend. If that isn't the case, it may be some kind of JS error, but more likely you are ending up with invalid data in the system somewhere that causes Magento to choke during checkout.
Also (just thought of this, haven't tried it), try the multi-address checkout. As I recall, it uses regular page posts, and may even have more useful messaging than the OnePage checkout. Please edit your post with your findings from the above so that we can help more if that doesn't do it.
Hope that helps!
Just in case someone gets the "Quote totals must be collected before this operation." error, and none of these solutions fixes their particular problem, I'll mention that mine was an issue with this:
skin/frontend/base/default/js/opcheckout.js
var params = Form.serialize(payment.form);
There was a JS error unique to this site which was clearing the Payment form and preventing JS from reading it's contents. The module or theme that you use will differ, but check to make sure that the payment form can serialize correctly. If not, then that could be your problem.
I had the very same problem on my store Princessly:
It takes about 20 to 130 seconds or even longer for "Submitting order information ..." to go through and redirect to the payment gateway such as PayPal, if at all, after clicking the Place Order button, last step of one page checkout.
If it doesn't go through, very probably because something timed out since it took too long, it will redirect back to shopping cart, leaving the customer an empty cart and a Pending Payment order, OR, it will give the exception of:
Quote totals must be collected before this operation.
Since obviously, well, something timed out and the script ends before quote totals are collected (which is just my theory), thus sending the Payment Transaction Failed Reminder email.
After 12 hours of research and debug, I finally found the culprit and the solution.
Magento enables RSS stock and new order notification by default, so every time Place Order is pressed ('sales/order' resources are then saved), cache is refreshed so RSS will be published. Cache cleaning can be very time-expensive for Magento. Therefore the solution is simple. Just disable RSS notification for save of 'sales/order' resources.
Find /app/code/core/Mage/Rss/etc/config.xml and locate this block:
<sales_order_item_save_after>
<observers>
<notifystock>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterNotifyStock</method>
</notifystock>
</observers>
</sales_order_item_save_after>
<sales_order_item_save_after>
<observers>
<ordernew>
<class>rss/observer</class>
<method>salesOrderItemSaveAfterOrderNew</method>
</ordernew>
</observers>
</sales_order_item_save_after>
Simply remove or comment it out and refresh Magento cache in System => Cache Management => Select All => Submit.
Now it only takes 1 second or even less for my store to go through Place Order and redirect to payment gateway.