I'm new to Fiddler and have run across something that seems strange to me. If I select an entry and then click Replay, I get different behavior from when I drag an entry into the Composer window and click Execute.
Should the different behavior between these two methods of re-making a request be different?
Note: I called the second method "cloning" a request because the Composer window says "You can clone a prior request by dragging and dropping a session from the Web Sessions list)."
What is the "different behavior" specifically?
The two operations you describe should behave the same way unless the server returns a redirect or an authentication challenge, in which case preferences will control whether Fiddler automatically authenticates and/or follows the redirect.
Please feel free to email me (Help > Send Feedback) details and/or screenshots of the difference you see.
Related
I'm running Fiddler for .Net 4.6.1 v5.0.20202.18177
In the Fiddler options dialog I have "Caputre HTTPS CONNECTs", and "Decrypt HTTPS traffic" enabled"
I have Postman installed on the same machine, with Fiddler set as its proxy. I make a https call to a cloud web service from Postman. I see a session row in Fiddler with a Host of "Tunnel to" that hits the URL of the web service.
If I select Help\Troubleshoot from Fiddler then it also shows the "real" session with the request and response payloads. If I right-click the "real" (filtered) session and select "Comment" then the following is displayed, repeated many times:
"Hidden due to FTS>Path"
I'm trying to prevent this "real" session being filtered. I've checked the filters at the bottom left of the Fiddler screen and none of them match. I don't have the filters tab enabled.
How can I prevent my "real" session from being filtered?
FTS stands for Filter Troubleshooting and "FTS>Path" means that you have a Path filter (i.e. Hide '/xxxxx/') that is filtering the request.
I suspect there's not a lot of room for error here, there can be a vertical scrollbar and unless there is Unicode or symbol trickery, it seems pretty straightforward.
My bad, I did have a filter set, I just couldn't see it because it was off the bottom of the screen. I didn't see a vertical scrollbar but I discovered that filters can be removed by right-clicking their name. So, I right clicked about 30 times in order to remove all filters - then I could see my traced request again.
I've been playing around with building some realtime functionality using Sails.js version 0.10-rc5 (currently the #beta release).
To accomplish anything, i've been following the sweet SailsCast tutorial on this subject (sailsCast link)
It talks about subscribing to a model via a 'subscribe' action within the model's controller. Then listening to it at the client side, waiting for the server to emit messages. Quite straightforward, although I do not seem to receive any messages.
I'm trying to do this to get real-time updates on anything that changes in my User models, or if new ones get created.. So I can display login status etc. in real time. Pretty much exactly the stuff that's explained in the sailsCast.
In my terminal i'll get two things worth noticing, of which the first is the following:
debug: Deprecated: `Model.subscribe(socket, null, ...)`
debug: See http://links.sailsjs.org/docs/config/pubsub
debug: (⌘ + double-click to open link from terminal)
debug: Please use instance rooms instead (or raw sails.sockets.*() methods.)
It seems like the 'subscribe' method has been deprecated. Could anybody tell me if that's correct, and tell me how to fix this? I've been checking out the reference to the documentation in the debug message, although it just points me to the global documentation page. I've been searching for an answer elsewhere, but haven't found anything useful.
The second message I'm getting is:
warn: You are trying to render a view (_session/new), but Sails doesn't support rendering views over Socket.io... yet!
You might consider serving your HTML view normally, then fetching data with sockets in your client-side JavaScript.
If you didn't intend to serve a view here, you might look into content-negotiation
to handle AJAX/socket requests explictly, instead of `res.redirect()`/`res.view()`.
Now, i'm quite sure this is because I have an 'isAuthenticated' policy added to all of my controllers and actions. When a user is not authenticated, it'll redirect to a session/new page. Somebody must log in to be able to use the application. When I remove the 'isAuthenticated' policy from the 'subscribed' action, the warnings disappear. Although that means anyone will get updates via sockets (when I get it to work), even when they're logged out. - I don't really feel like people just sitting at the login screen, fishing out the real time messages which are intended only for users who are logged in.
Can anyone help me getting the real time updates to work? I'd really appreciate!
As far as the socket messages not being received, the issue is that you're following a tutorial for v0.9.x, but you're using a beta version of Sails in which PubSub has gone through some changes. That's covered in this answer about the "create" events not being received.
Your second issue isn't about sockets at all; you'll just need to reconsider your architecture a bit. If you want to to use socket requests to sign users in, then you'll have to be more careful about redirecting them because, as the message states, you can't render a view over a socket. Technically you could send a bunch of HTML back to the client over a socket, and replace your current page with it, but that's not very good practice. What you can do instead is, in your isAuthenticated policy, check whether the request is happening via sockets (using req.isSocket) and if so, send back a message that the front end can interpret to mean, "you should redirect to the login page now". Something like:
module.exports = function (req, res, next) {
if ([your auth logic here]) {
return next();
}
else {
if (req.isSocket) {
return res.json({status: 403, redirectTo: "/session/new"});
} else {
return res.redirect("/session/new");
}
}
}
My scenario:
I navigate to a login page.
I put in a known username with a bad password.
ZAP picks this up no issue.
I select the POST to the login page.
I find the lines that contain the Username and password. The password:
ctl00%24ContentPlaceHolder1%24cpLoginAspx%24ctl00%24LoginControl1%24LTLogin%24Password=12345&
I highlight the 12345 and right click to select Fuzz.
I had put in a custom list with the correct password for the test account and I select that.
When I do, it works its way through the list as I expected. Changing the 12345 to the various options in the list.
But, when it gets to the word I KNOW is the correct password. It does nothing different to alert me that it was correct. The password in this case was Password5. I expected that it would reflect or something showing it was directed to a new page. But, that happens for 'password' which is not correct for the test user.
I see this in the Fuzzer tab:
OK, I think the first point you're raising is that ZAP doesnt pick up that you've tried an invalid password. That is not a security risk - you supplied a bad password, the app didnt let you in. Everything's working as it should.
ZAP will only alert you of vulnerabilities via the active or passive scanners.
The fuzzer is for manual testing. If we work out a way to automate the detection of a vulnerability then we put that in the active or passive scanners :)
So you have to interpret the fuzzer results rather than expect ZAP to do that for you.
In any case, successfully logging in is not a vulnerability (in ZAPs terms).
What the fuzzer will tell you is if the string you supplied was included in the response (which is useful when looking for XSSs), the response code, the time taken and the response length.
When logging in I'd expect that the response length would be significantly different, so one option would be to look for a response with a length significantly different to the others.
However the easiest option is probably to search the fuzz results.
To do this go to the Search tab, select 'Fuzz Results' in the pull down and either search for a string that you know will be shown when you successfully log in, or do in inverse search for a string that you know will be shown when you fail to login.
Does that help?
Note that we do have a load of info on the ZAP wiki, including videos, FAQs and much more: http://code.google.com/p/zaproxy/wiki/Introduction
BTW we do have a ZAP user group which is intended for exactly these sort of questions: http://groups.google.com/group/zaproxy-users
You can also access it via the ZAP 'Online / ZAP User Group' menu item.
I try to keep an eye on forums, but there are so many that some questions are bound to slip through.
If anyone can suggest how I can convince people to use the ZAP user group (which all the ZAP developers subscribe to) instead of general purpose forums like this (which is very useful for other questions) then I'd be very grateful :)
Simon (ZAP Project Lead)
I have a multiple publish instances and multiple dispatchers in Production environment of my website. While i see net tab in firefox, i see a failed request of tracker.js directly hitting to dispatcher URL.
GET http://web.dispatcher.com/libs/wcm/stats/tracker.js?blah-blah
where web.dispatcher.com
I feel dispatcher URL should not get exposed like this. And why even it is hitting dispatcher URL. Any ideas?
I feel either turn off the impressions tracker but not sure how to do that? Or rewrite the request to hide dispatcher. Any suggestions? And How to do it?
if you go to [host]:[port]/system/console/configMgr you will see a configuration for "Day CQ WCM Page Statistics"
Modify that to configure the full url where you want the tracker to send it's requests to.
Additionally, this XHR request is generated by stats.jsp, which is generally included in your head.jsp. If you simply remove that script include from your template (or change it to conditionally include, ie. to not include when WCMMode==DISABLED) you can stop that request from being generated.
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.