feature request: Disconnect when quit
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- c
- Domain
- desktop, networking
Research direction
Start by locating the existing Disconnect control and the UI's quit or close handling for the Windows desktop application. Trace how network connections are managed when the UI exits, then verify that the requested setting disconnects networks on quit without changing normal disconnect behavior.
Written by the indexing model from the issue text.
Description
I join many different networks. Since there's only "Disconnect" button here, I have to remember to check all networks and disconnect which I don't really trust before I quit the UI. When the UI has been closed, it can be easily forgotten that I'm still in that untrusted network thus been vulnerable to potential attacks.
I think a "Disconnect when quit" button is better.
ZeroTier 1.10.1
Windows 10
- Dominant language
- C
- Stars
- 233
- Forks
- 43
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from zerotier/DesktopUI
-
Difficulty 3/5 1-2 days Newbie friendliness 50/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
All issues in zerotier/DesktopUI
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
FujiNetWIFI/fujinet-lib#115 · 1 comment ·
Maintainers usually reply within 1 day
-
firmware: transmit() doesn't reset rfTxCurBufIdx, so RFxmit after RFxmitLong can send wrong bytesPossibly taken @hermes-crew-337 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
atlas0fd00m/rfcat#182 ·
-
followup
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 4 days
-
question
Difficulty 2/5 1-3 hours Newbie friendliness 68/100