https:// gives CSRF verification failed.

NSPManager / NSPanelManager

Sonoff NSPanel custom firmware for responsive and intuitive use

https://nspanelmanager.com/

128 stars 10 forks source link

https:// gives CSRF verification failed. #87

Open h3n3b0sch opened 10 months ago

h3n3b0sch commented 10 months ago

I have NSPanelManager installed in Proxmox in a LXC container using an Alpine-docker container.

There is reverse proxy via Nginx Proxy Manager with a Let's Encrypt SSL certificate. This SSL gives problems with contacting the panels and when saving anything to the panel it gives a Forbidden (403) error:

When opening the NSPanel Manager via http:// everything looks just fine:

Anyone got a solution to get https:// working?

h3n3

P.S. Great job btw, this NSPanelManager!

aaronouthier commented 10 months ago

When accessing the panel manager from inside your home network, I would suggest using the IP address of your nspanelmanager directly from within the individual panel's UI, over http.

If you worry about security and feel that you need to access via HTTPS, then you'll need to run your own DNS server in your LAN/Home network.

Research "Split-brain DNS".

The issue you are likely having is, the domain name doesn't exist inside your LAN, so traffic from your individual Panel(s) is/are going out to the Internet, and then coming back in via your port forwarding on your router. Most home routers don't handle that situation properly.

You can try running OpenWRT/DD-WRT, or PFSense/OpnSense if you have supported hardware. The easier method might be to run something like PiHole. If you don't want the blocking, just remove the blocklist, and run the DNS Server.

aaronouthier commented 10 months ago

Doing a whois lookup, the domain name opdethuisserver.nl doesn't seem to exist. Neither does nspmanager.opdethuisserver.nl . However, that could be a problem on my side. Are you sure those names exist?

h3n3b0sch commented 10 months ago

Doing a whois lookup, the domain name opdethuisserver.nl doesn't seem to exist. Neither does nspmanager.opdethuisserver.nl . However, that could be a problem on my side. Are you sure those names exist?

Yes, it is my own.

I have pi-hole running here, maybe i'll look in to that.

Still wondering... the settings of the panel are in IP-addresses not the domainname, why can't it get the status of the panel?

tpanajott commented 10 months ago

Doing a whois lookup, the domain name opdethuisserver.nl doesn't seem to exist. Neither does nspmanager.opdethuisserver.nl . However, that could be a problem on my side. Are you sure those names exist?

Yes, it is my own.

I have pi-hole running here, maybe i'll look in to that.

Still wondering... the settings of the panel are in IP-addresses not the domainname, why can't it get the status of the panel?

The actual status of the panel is gathered over MQTT and is then fetched through a websocket connection to the container when displaying the web interface. Have you allowed port 8001, which is a websocket, to the container?

h3n3b0sch commented 10 months ago

The actual status of the panel is gathered over MQTT and is then fetched through a websocket connection to the container when displaying the web interface. Have you allowed port 8001, which is a websocket, to the container?

It is allowed, without the https it connects.

h3n3b0sch commented 10 months ago

For now I have disabled the outside FQDN because I realized it is unsafe without having a login page, eventhough it is not possible to change anything. I have no understanding of Django (yet) but if I can find the energie and time I will try to implement a login page.

For now I will put this issue on a hold until then.

tpanajott commented 10 months ago

You could try and set the trusted origins for the CSRF validation, example: CSRF_TRUSTED_ORIGINS = ['https://front.bluemix.net']

This should be added to the setting.py file in the container. If it works it's easy enough to add it as an environment variable for the container.

tpanajott commented 10 months ago

For now I have disabled the outside FQDN because I realized it is unsafe without having a login page, eventhough it is not possible to change anything. I have no understanding of Django (yet) but if I can find the energie and time I will try to implement a login page.

For now I will put this issue on a hold until then.

It wouldn't necessarily be unsafe if the FQDN is only available in your network and the address is firewalled from the internet/untreated networks, in that case it's just a helpful name instead of remembering the IP.