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
Allow arbitrary URL rather than IP #14
Comments
Yes, great idea. I will implement this as soon as I have passed my exams. For now, free time does not exist. Regards, |
I start working on it. I now use the zeroconf protocol to fetch the device IP. |
See commit. |
I would suggest to expose a setting option to let the user choose the ip and address url to configure before using the hostname and ip. In a homelab, let the dns do it's work. And similarly for turning on or off ssl and using reverse proxy. |
It is already possible to edit the server IP and server API token, however, it is not possible to edit the zeroconf type.
|
I was refering to the address url, e.g. The main use-case for all of this in particular is to have interoperability between receipt-parser and grocy. |
Never used caddy or grocy before but I will take a look at it. I now enable insecure HTTP requests if needed. Use the latest receipt parser app |
Looking at the commits, it is coming along nicely, I'll give it another go when I can. Still didn't find if inputting URL instead of IP is coded yet. I believe the only issue is the check filter for if it's a valid IP, otherwise the base libraries should be able to do the dns resolving for you. Unrelated but is there a reason for implementing TLS min version 1.1? To my knowledge 1.1 is deprecated and should not be used moving forward. |
Your right. TLS 1.1 is deprecated and will be replaced with TLS 1.3. Thanks for catching! In terms of security, there are additional bugs:
I will assign myself for this. If you find any other bugs, please let me know. |
I will implement this feature today but the zeroconf type has limitations. This format is needed: |
I don't develop on java, python or android so I'm not familiar with the tools available. What exactly is zeroconf's role? If all the tools just read the relative URL part, i.e. anything after the IP/domain, then simply allowing the platform to do the heavy lifting will be sufficient. If you want to give it a go with caddy, just use something like this in the Caddyfile, and point what private/public DNS you have access to to the appropriate ip/nat and you should be good to go.
I am unable to do any tests for a few weeks, but I don't remember having had any problems accessing the receipt server using reverse-proxy. |
I remember one application which also uses only gunicorn or uvicorn. Maybe check DashMachine for reference. I remember that I didn't had to do anything fancy when setting it up, didn't even had to provide the serving URL. |
Well, zeroconf is not a tool, it is a protocol. The zeroconf protocol is used to receive the server configuration without human intervention or special configurated servers. In this project zeroconf is used the following:
But not the API token. I like this approach, since it only depend on the python zeroconf library and the bonsoir flutter library. |
I think DashMachine uses flask and not fastapi. See here. |
So it is not linked to dns or how the URL is handled. If you only use it for those, you should be able to emulate it by serving the basic information in json format at the root url. Heck you can even use fancy techniques like DNS SRV records or But the URL issue seems to be unrelated and can work in parallel with the zero-conf service. I suggest that just on the client side, you don't have the user input an IP, but instead any URL and don't worry about getting the server IP from there, just use that as the base URL. Everything else should work just fine like that, except not being able scan for zero-conf outside your network. The main difference from using the IP approach is that
|
Yes that is the case. I was just looking at the gunicorn settings and how it is called to see if they need to resolve the server's IP, and in that case they don't |
Yes, this was a design decision because I never thought that there is an application for this thus there might is. I was confused because I thought this is clear. Thus there are some steps necessary to make this work.
Thanks for pointing me to this issue. I really appreciate this input! |
In most situations it would be semi-public accessed through vpn. But I do see applications for having it public, e.g. when finished shopping or dining, you are more likely to remember to archive the receipt. About the tls, appreciate the work for setting it up, but would you consider offloading all of this to the reverse_proxy? I see the reasoning as follows:
Can you point me to some basic api path to test? I did some quick connectivity tests behind a reverse proxy and I do get json responses for api not found. So this approach seems to work out of the box for the server part. |
Sounds good and I agree with both points.
Sure, there are two main API entry points.
|
See: f66f456 |
You can try it and share feedback! Regards, William |
Can you package or pre-release the latest commit? |
Yes, I prepare a pre-release. |
You've uploaded |
Yes, your right. I bumped the receipt-manager version now. |
The connection works. One complaint on the server side, but I'll post it there. A few notes:
|
Total agree with all points. Great feedback, I appreciate the input or requests! Could you please create a new issue for every:
That would be helpful. Regards, William |
Migrated them, so this issue can be closed |
Update, even I use now a reverse proxy and it does work very well. Thanks for requesting. |
Welcome to the world of self-hosting :). I can also suggest the subreddit |
Simple as that. On the server side you could serve some basic info of the server to check via json API if the location is a receipt-parser server or not.
The text was updated successfully, but these errors were encountered: