Open arctumn opened 1 year ago
Summary of what was said in discord for quick reference: This feature has little to no use as it is just a rehash of the console but with "access" from other computers. The author proved the idea that you could open this up to be accessed from anywhere outside of your home, however, while this is a fair point it does also take a good bit of know-how in networking, along with exposing potential security holes in a local network. It was also brought up that this being used "outside of your home" is already solved by webhooks being in the farmer already.
Overall it's a good implementation of a simple web app, but as seems relatively unneeded for most if not all users, especially when you account for the new requirements for hosting a local webserver, along with the potential for security risks (yes these are essentially negligible, but opening a network to the internet is always a risk).
From what I've seen there are some users insterested in a non command line version of the app.
I also noticed with current changes I've done with the idea given in discord on allowing those settings to be adjusted in docker/.env, makes this no longer simple for a basic windows user to setup the web-server.
In terms of security the application is only visible to outside the computer that is running when you change the host from localhost to anything like an IP or a DNS, when the host is localhost there are by default no straight way to access the app outside the pc that's running it.
Also it provides a more user friendly way to check their status than the GUI that can get stuck.
About the Discord Webhooks I don't see them as an easy alternative to check remotly your status from a normal user.
This change also possible allows a future develop of more features like setting the accounts via web directly to the app without needing to probably restart.
In the end I think should be the user to decide where they want to see their status, on my behalf I think a web page is way less tech savy than a CLI adjusting directly.
Shure, I'd believe that there are some people looking for a feature like this, and like I said its a good implementation of such a feature, however also like I said, if you don't intend to port forward this (which is how you would access it outside of your house, an example you gave, and also where a possible security hole comes from), then there is no reason for this. As I brought up earlier you can simply check the console. As for "user friendliness", sure after it's set up id agree with that, but in the process of setting it up, you run into again the issue of port forwarding "it does also take a good bit of know-how in networking". To address the end, arguably yes, a webpage is less tech-savvy, but when the data is presented right there in the exact same format on something that opens automatically just by double clicking a .exe
, which most users are used to doing, I'm not too sure how navigating to localhost:8080 is any easier than just clicking the console in the taskbar.
It's again a good implementation of a web app into the farmer, but as presented it does not make sense as an alternative for "less tech savvy" individuals.
Overall an interesting idea, but especially for running this with docker, you can just use tools like Portnainer to view the console on the go, which are tested to be secure and properly manage the data.
An idea to expand on the discussion of 'less-techsavy users' would be to create a website somewhere that tracks the farmer stats using a key, and any user that knows this key can view that data. Would require much less work for the user, keep it simple, but it does require said tool to exist. If this is something appealing for you to work with, I can spin up a simple proof of concept later today.
I already have implemented something like this. There used to be discussion if we should track the number of users using the farmer. I think the code could be reused for this purpose if we decide to implement remote status checks. It was only a heartbeat though.
To be honest I would rather not be tracked from a website that tracks farmers unless I asked for that, if I want to see my stats outside the farmer marchine, I would rather have my web-server doing that, on the other hand for most users probably its a good idea to have a website that allows them to easly check their status outside their own farmer.
Still having your own web-server vs a global web-site that everyone can see its a bit more private.
So the idea is:
However there is a problem with the third option, by choosing that, it requires things like DNS(users that choose this probably don't want to put an IP address), better server to hold users that access to the platform, a database(with user data?) all those things cost extra money to run, so like have the third option like a paid/ads? option so it's sustainable.
In the end the second option it's the one that allows some privacy and some easy access to checkout their status.
Fixes #160
Summary of Changes
Adds a flask web-server and a flask-socketio web-socket Adds a web browser page that gives the status of the users Does not block the GUIThread from work Does not implement any kind of authentication from the flask server pure visual changes Adds a way to check the service from the web Adds a controllable way to enable and adjust the web-server via config.yaml
Additional context
Visual result, subject to changes:
Discord username (if different from GitHub): arctumn#9829
How to enable the Poro-server
To simply enable the Poro-server you have to add a web-server information to the config.yaml
Example of the settings on the new config.yaml
In case there is no config.yaml the default values will be loaded:
This means that by default the web-server is disabled, and can be easly enabled by adding those config files.
For docker users they just have to expose the port they want to access the web-server after configuring theirs config.yaml
Testing instructions
Needs to check missing cases that is not contempling like possible error messages that are missing,
How to download the PR for testing
Using GitHub CLI
gh pr checkout 124
(Requires GitHub CLI)Using regular GIT
git fetch origin pull/<PR_NUMBER>/head:<LOCAL_BRANCH_NAME>
(e.g.git fetch origin pull/110/head:notif
)git checkout <LOCAL_BRANCH_NAME>
(e.g.git checkout notif
)