improv: error cleaning and local state storage in $APP. #3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Working Build Feature
Why is this needed?
This change moves the configuration file
wg0.conf
from the tauri$RESOURCE
to$APP
. This removes the need for administrative privilege escalation. This is a working build, accommodated with the switch to CA verified SSLcertificates using cloudflare.
Context
This moves the build from a perm-locked to perm-free version. Upon building, the app folder is created and establishes presence. This was required, as reseda was running into issues with storing and managing files, where it was unable to access the file due to its placement in Program Files. This was conjoined with its issues in SSL verification as the servers were still on HTTP (unsecure) connection handling protocols. Hence, reseda moved from name.com to cloudflare for DNS, which has a free wildcard SSL layer for proxied connections. Hence, after moving to cloudflare, (although manually) connections work perfectly under a cloudflare.
Drawbacks of Implementation
(references reseda-server): By using cloudflare, the service is more protected against attacks and has SSL TSL socket protection for handling and creating connections. However, there is one drawback of this implementation. This is the SSL subdomain assignment, as currently I am unable to dynamically allocate subdomains for the SSL layer as servers come up and down. Hence, a further implementation of pinging and dynamic up/down server status management must be upheld in order to verify server integrity. Furthermore, as dynamic allocations of subdomain DNS's which are now relied upon for connection (indisputable), new servers must be manually added to the cloudflare network. This is a concern for future scaling, and so forth actions will be taken to mitigate or circumvent these issues.
Features: