-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
4 Usability Suggestions #28
Comments
Agree. It'd be useful for the other tabs as well. Sometimes I want to look for a particular host or ip, but the list is too big and it's a bit tedious.
The only problem with this is that when a pop-up notification is displayed, all connections are queued, which can lead to timeouts or drops. It needs to be changed, which would allow us to even get rid of the pop-up notifications if the user choose to do so. On the other hand, as the user can change it from the rules editor, I don't consider it urgent for now.
Yes, this is in fact a bug. It also happens on the other tabs.
Already done :) You can test it by copying this file to /usr/lib/python3/dist-packages/opensnitch/dialogs/: |
I don't really see why that affects/prevents this? Already, when there's a popup you can configure allow/deny, whether it applies to the port, IP, domain, subnet, etc (i.e. via the "+" button). This would simply supplement those already-configurable items with one more: an input box for the rule name. The big advantage being that if you do need to go back to the UI & make revisions later (or even right after), it'd be considerably easier to locate the rule - no need to dig around trying to figure out which one it was that you just added, as you've clearly named it yourself :) |
Now when you enter into the details of a view (rules -> view rule), when going back to the main view the order is preserved.
Completely agree. The default name was fine while we couldn't edit it from the GUI, but now it can be improved. It wouldn't need too much work, maybe I can add it this week if I have time. If others are reading this, I'd love to hear more opinions. The problem is that when the pop-up is displayed, due to the way it is currently implemented, it blocks all the network traffic until the pop-up is closed, regardless what you configured as the default action. The change should be to let the traffic pass and apply the default action configured until the pop-up is dismissed. But this change will take me more time to implement it. |
sort order fix, I hope. Copy this file to test it: |
|
The thing is that it's refreshed when there's a new connection. So it can pass several seconds until it's refreshed. I'll fix it this week.
Right now there're 3 timeouts in opensnitch when a connection is about to be established:
The 3rd timeout is not configurable. I remember had seen it a while back, but I haven't had the opportunity to make it configurable. So if you don't answer a pop-up in 30s (regardless of what is configured in the UI), then the daemon considers that it's not connected to the UI and applies the default conf:
This is what I was referring to that it needs to be changed before allowing to edit the rule name from the pop-up. But this bug is going to take more time to be fixed. |
I still don't see how they're related though? They seem to be 2 totally distinct issues: one is a textbox that lets you modify the autgenerated name (regardless of timeout), and the other is cleaning up the timeout situation (whether or not you can edit the name). |
Requested here: #28 Previously we could filter data only in the General tab, but the Hosts and Addresses lists tend to be huge, so allowing to filter it helps to find a host or IP quickly.
I've been analyzing this timeout and there's a major problem: the rule is not added to the rules list (UI and daemon) if this timeout is fired before the user allows or denies a connection. So for the next release I'll just increment the timeout value enough to let the UI timeout fire, and find a better solution for the next release. |
Explained here: #28 (comment)
It was not being refresh properly. Mentioned here #28#issuecomment-633700103
fixed this week O:) |
This firewall is amazing. I'm so glad someone decided to continue the project so it didn't end up disappearing - thank you!
After a day or so of use, I have 4 smallish suggestions that I think would make a huge difference to usability:
Thanks again for the great work!
The text was updated successfully, but these errors were encountered: