When i find the Tariff how to save the filter list for the next reboot ? https://i.stack.imgur.com/7KZEj.jpg
Fiddler does not presently offer that feature. Vote here https://fiddler.ideas.aha.io/ideas/FID-I-114
The answer is to use the method from Filter Fiddler Traffic.
Typically when using Fiddler you should use the Filters tab or FiddlerScript and specify exactly what you want to see in Fiddler. Filters will be saved when restarting Fiddler.
Also, in addition to being able to save the filter, I find that whitelisting what I want to see (Filters) is more convenient and effective than blacklisting what I don't want to see (Filter Now). You will usually not be able to filter away all the many types of requests that you don't care about, and are probably only interested in a couple types of requests. So just specify those.
Related
I'm wondering what are the best ways to delete items from a subset in a restful way. I got users and series, each user has his own list of series (watching, completed, etc). For example, if we want to get a list from a user we can do it with: GET /users/:id_user/series
If we want to delete a serie from the list of that user (but we don't want to delete the serie itself), how should it be?
I thought about the possibility of using DELETE /users/:id_user/series/:id_serie, but I'm not sure if it's the correct way for this case (maybe PATCH?).
I got another case, we got series and reviews. We can get the reviews like this: GET /series/:serie_id/reviews. In the other case we didn't want to delete the serie itself when deleting from a user list of series, but in this case we want to delete the review because its existence depends on the serie. So I guess in this case DELETE /series/:serie_id/reviews/:review_id is correct.
Is this difference important in order to choose the rest operation to delete the object/item from the subset?
How would you do it on the web?
You'd follow a link to a form, with input controls. You might have a something like a dropdown if you wanted to delete one series at a time, or lots of check boxes if you wanted to support a bulk delete. The user would provide input, hit the submit button, and the browser would create an application/x-www-form-urlencoded document and send it to the server.
What method would be used? Normally POST, because we are intending an edit to some resource on the server.
What resource would we be editing? Well, in trutch, it could be anything -- the server would include that information in the form metadata, so the client can just do what it is told.
So where should the server tell it to submit the form? Again, it could be anywhere... but a useful approach is to think about what resource in the client's cache is being updated. Because if we send the request to that resource, we get intelligent cache invalidation "for free".
So on the web, we would expect to see:
POST /users/:id_user/series
Does it have to be POST? On the HTML web, maybe it does, because the ubiquitous client of the web is a browser, not an editor.
It is okay to use POST.
But a perfectly valid alternative would be to edit the local copy of /users/:id_user/series, and then send back to the server a complete copy of the new version (PUT) or a patch-document describing the edits (PATCH). Notice that with both of these choices, the target uri is still /user/:id_user/series, so we still get the cache invalidation magic.
Creating a new resource in your model just to have something to DELETE is probably the wrong idea.
There are cases where an edit, or a delete, will necessarily impact more than one resource.
There are some specific circumstances when you can get the right magic cache invalidation with two resources (for instance, delete one document, and send back an updated copy of another).
But we don't, today, have a general purpose cache invalidation mechanism. (Closest thing I've been able to find is this, which seems to have stalled out in 2012.
I'm starting to integrate PayPal checkouts with a server workflow.
My basic need is to create an order on the server and ensure that the client can not modify it in any way.
Because of this requirement, I have already ruled out using the "simple" JavaScript-only solution, and I'm instead going for a server integration, calling my own URL endpoints for creating and capturing orders.
However, I have found that the client can just ab-use the actions.order.patch() method to modify almost every aspect of the order, including the amount and the custom_id that I'm attaching to the purchase_item.
Basically, It looks like I have absolutely no guarantee on the order contents, even if I created it on the server, is this correct?
In that case, it means I have to check each order's contents against the orders database of my application. It is possible, but I was hoping to not have to do that.
Any clues? How do you deal with this issue?
Thanks!
If you are particularly concerned about this scenario of patching down the total or other details before capture, the only way to ensure it has not changed is to do a server-side ‘get details’ call before the capture and at least validate the total amount value, as well as any other field you’re concerned about.
Otherwise, the usual general safety solution in ecommerce (for this as well as other potential issues that might crop up) is to simply capture and validate the total in the capture response. If the capture has a total you don't expect, issue an immediate refund or flag the occurrence for review before fulfilling anything.
I know that from most of today's REST APIs, web calls responses have to be paginated.
But, I don't see on the web any insight on how to select the ideal size of a batch returned by an API call: should it be 10, 100, 1000. To be short: on what factors should we base the reflection of the size of an API response?
Some people state that it should be based on the number of elements displayed by the UI. I don't agree with this, as not all APIs are directly linked with an UI, and, in any cases, modern REST APIs allow to chose the number of items in output batch with a configurable parameter up to a certain amount.
So, how could we define the value for this "maximum number of elements returned by an HTTP request"?
Should it be based on the payload size? Internal architecture of the API? Should it be based on performance measurement?
Any insight on this? I'm not really looking for an explicit figure, but more some techniques that could help to find the answer. The best for me would be the process followed by some successful APIs. But, I cannot find any.
My general approach to this is to:
Try to avoid paging
Make REST clients resilient against paging changes, by using next and previous links, instead of using a ?page= attribute. A REST client knows another page is available strictly by the appearance of the link.
I don't use hard rules or measurements to figure out when paging is needed. Paging is generally painful, so my first approach would be to try to figure out what requirements drives the need for paging, and if that requirement can be removed.
Once I've determined it's not possible to remove this requirement in another way, I would set the cut-off of a page as large as reasonable, to remove the likelyhood clients need to do additional requests.
If it's a closed API (used only by clients you control), pick whatever the UI wants. It's trivial to change. If clients can choose from several options, you can include a pageSize parameter. Or, better..
If it's an open API (used by clients you don't control), then let clients control what size paging they want. Rather than support a pageNumber parameter, support offset and limit. Offset is how many records to skip before starting to return records, and limit is the maximum number of records to return. If the client is not happy with how their request performs, they can adjust the parameters to suit their needs. Any upper limit your API has should be driven by what your service can handle. It's neither possible nor desirable for you to try to figure out the Magic Maximum Page Size that makes all clients happy and no clients sad.
Also, please note that none of this has anything to do with ReST, which is silent when it comes to paging.
I usually make a rough performance measurement by hand. I want as few requests as necessary, but do not want to risk timeouts.
Hi everyone and sorry for my bad English.
I'm learning penetration testing.
After reconnaissance and scanning of my target, I have enough information to pass to next phase.
Some info I have is open ports with related running services, names of the services, service's versions, operative system of the device, firewalls used, etc.)
I launched the mfs console.
I should find the correct exploit and payload, based on the information collected to gain access. I've read the Metasploit Unleashed guide on offensive-security. I've learned the Metasploit Fundamentals and the use of mfs console.
But I don't understand the way to start all of this. Assuming that my target has 20 ports open, I want test the vulnerability using an exploit payload that do not require user interaction. The possibilities of which exploit and payloads to use are now reduced, but are always too. Searching and testing all exploit and payloads for each ports isn't good! So, if i don't know the vulnerability of the target, how do I proceed?
I would like to be aware of what I do. and do not try without understanding.
Couple of things:
We have a stack exchange for security! Check it out at https://security.stackexchange.com/
For an answer: you want to look for "remote exploits", as those do not require user interaction. you can find a curated list of exploits here: https://www.exploit-db.com/remote/
You can search the services on this page for something that matches the same service/version as your attack vector.
In this question's comment, EricLaw (the author of Fiddler) wrote:
Fiddler has lots of interesting
features, but not all of them are
super well-documented. A related
question would be: "What do you wish
Fiddler could do that it can't... or
that you can't figure out how to do?"
– EricLaw -MSFT- Nov 2 at 2:54
Following the lead - what do you want from Fiddler that it doesn't have now (or you don't know whether it has)?
I'd like it to be able to format and pretty-print XML and JSON request/response bodies, e.g.
so a raw:
<SomeElement><Nested><MoreNested>X</SomeElement></Nested></MoreNested>
Could be displayed as:
<SomeElement>
<Nested>
<MoreNested>X</SomeElement>
</Nested>
</MoreNested>
Would be really useful when looking at our API calls.
I know it can do the XML tree view, but I'm more comfortable looking at raw markup so I can see exactly what's going on. I'd just like to look at the raw markup in a nicely formatted and coloured way!
The Inspectors tab has a WebForms button, which is very nice for checking x-www-form-urlencoded POST data, but as soon as the form is multipart/form-data (e.g. forms with file uploads), this button can't display it. Or can it?
I'm not sure this is really a programming question... But, one feature I'd like is to be able to configure a standard set of screens on the right side. I always use raw mode, for example, and have to reset it every time I start the app.
Another is that I would love to have it work in a mode where it snoops on the TCP conversation, rather than acting as a proxy, along the lines of tools such as IBM Page Detailer. The problem is that browsers interact with proxies differently than they do when they're talking directly to hosts.
I hope I can select which process to watch.
not only browser or not-browser option.
I'd really like to increase the latency between the request header of an HTTP POST and the request body. I can see how you can increase the latency of the entire request as a whole, but not the individual packets.