mirror of
https://github.com/ProxymanApp/Proxyman.git
synced 2026-04-25 16:15:55 +03:00
[GH-ISSUE #913] [Nice to have] Allow to hide useless requests (without blocking them) #909
Labels
No labels
Discussion
Feature request
In Progress...
Plugins
Waiting response
Windows
Windows
bug
duplicate
enhancement
feature
good first issue
iOS
macOS 10.11
question
wontfix
✅ Done
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Proxyman#909
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @speekha on GitHub (Jun 22, 2021).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/913
Originally assigned to: @NghiaTranUIT on GitHub.
Proxyman version? Proxyman 2.24.0
macOS Version? mac 10.15.6
When I connect my Android simulator to Proxyman, lots of requests go through that have zero interest to me (either from third party libs or apps). All those request tend to clog logs a lot with pointless information. The block list option can allow to remove some of those, except that blocking the request can alter the behavior of my app. So instead of blocking completely the requests, I'd like to have an option to just hide those requests from the captured logs so I only keep the requests that make sense to me.
@NghiaTranUIT commented on GitHub (Jun 22, 2021):
If you use iOS Simulator, Proxyman is already hiding all unnecessary traffic from the iOS Simulator to Apple Server. However, it hasn't implemented for the Android Emulator yet.
Can you share with us the list of unnecessary APIs from your Emulator? and what kind of Android Emulator are you using (Android Studio Emulator or 3rd emulator)? 🤔
To workaround, you can either:
@speekha commented on GitHub (Jun 22, 2021):
Well there are actually a lot of different URLs transiting through proxyman on my project, on a lot of different domains.
So on one hand, the requests I'm interested in are on several domains, so filter won't really work (but I guess I could pin all those domains). On the other hand, it's not just standard simulator stuff I want to filter out : we include a lot of third party libs that send requests on a lot of other domains (analytics and other third party services). So basically there are lots of URL or domains I'd like to exclude, but also lots of domains to let through (and I'd rather exclude explicitly the ones I'm not interested in so I can notice anything unusual, rather than miss it because it's not in the pinned ones).
@NghiaTranUIT commented on GitHub (Jun 23, 2021):
So, if these unnecessary domains are not from a standard Android Emulator, it's impossible for us to automatically hide it.
On the other hand, it works for iOS Simulator, since they're all from *.apple.com.
I would like to recommend that you should pin your working domain, group it into a folder. Then selecting the folder -> It will list all traffic from these domains. Therefore, you can exclude other unnecessary requests.
However, it's a nice idea to implement a feature "something like Hidden/Exclude List", to hide these domains without explicitly blocking them.
@crankygeek commented on GitHub (Jul 2, 2021):
I think this is a dupe of my request #594.
@speekha commented on GitHub (Jul 2, 2021):
@crankygeek Agreed. Sorry I didn't see yours.
@crankygeek commented on GitHub (Jul 2, 2021):
@speekha No worries! I just wanted to link the tickets. I probably should have worded that better.
@NicolasCombe5555 commented on GitHub (Dec 16, 2021):
+1 🚀
@NghiaTranUIT commented on GitHub (Dec 17, 2021):
@NicolasCombe5555 if you don't mind, can you share with me what kind of traffic you want to hide from your app? 🤔 Is it ads, analytic traffic?
@NicolasCombe5555 commented on GitHub (Dec 21, 2021):
@NghiaTranUIT sorry for the late response. Mmm for example in my app I get periodically updates from open connections, if I add to the block list tho, the app does not behave like it normally would. So for example in that case it would be useful to just ignore a certain url pattern but not block it, so I do not have spam when I try to debug other things; I believe it would be useful to have this feature like @speekha said as well.
@chilikasha commented on GitHub (Jan 6, 2022):
Would also like to have this feature. I have numerous "subscribe event" requests which I would like to filter out.
@NghiaTranUIT commented on GitHub (Jan 6, 2022):
Thanks @NicolasCombe5555 @chilikasha and others. I understand that this feature should be implemented since it's recently gained more attention 😄
Just a simple mock-up: Instead of implementing a new tool (New feature), I suppose that I can improve the Block Tool.
By adding the option to:
I will implement and sent you guys a Beta build soon 👍
@NghiaTranUIT commented on GitHub (Jan 10, 2022):
Hey @NicolasCombe5555 @chilikasha @speekha @crankygeek let try this Beta build: https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_2.35.4_Hide_Request_From_Block_Tool.dmg
You can simply hide the requests, without blocking them 👍
You can simply create a rule by Righ-Click on the Request -> Tools -> Block List -> Select Block Action as "Hide, but not Block" 😄
@chilikasha commented on GitHub (Jan 10, 2022):
@NghiaTranUIT looks like it works as expected for me :) thank you!
@crankygeek commented on GitHub (Jan 10, 2022):
@NghiaTranUIT Looks to be working well.
@NicolasCombe5555 commented on GitHub (Jan 10, 2022):
@NghiaTranUIT working good! thanks 🚀🎉🎉
@NghiaTranUIT commented on GitHub (Jan 11, 2022):
Awesome, I will release this feature on the next version 🎉
@user1man commented on GitHub (Apr 24, 2024):
Hello everyone,
Thank you for your contributions to this discussion. It would be beneficial if we could mark this issue as resolved. This would assist anyone who comes across this thread in the future to understand that the feature request has been implemented.
Thank you for your understanding and cooperation.
@NghiaTranUIT commented on GitHub (Apr 25, 2024):
yes, it's done with the
donetag 👍