This tells you how the bridge works: http://moderntoil.com/?p=794
It would appear to me that the bridge has no real need for security as such since it only transmits data to acurite web site from your weather station using POST commands. It's security is controlled by your own router, and it would only respond to incoming data when it switched to update mode to update its firmware. On Monday, 10 October 2016 02:28:39 UTC+3, Tim Phillips wrote: > So I've totally misinterpreted what Apache does for the weewx > service....I'm super new to this so I'm sorry you need to explain these > things like this. My WAN/IP education is limited to setting up a handful of > foscam's on WAN manually as well as doing a RPi webcam project > (RPi-Cam-Interface) which worked well. > > I ALWAYS set a custom password on my stuff and change the username if > possible. Actually, I decided to use my RPi as a weather station server > because the Acurite "bridge" accessory gave no indication of how their > security works, which I disliked. So I took it as an opportunity to learn > all about it, hopefully via this project as a starting point. I was not > keen on just plugging in their bridge accessory to my router and thinking > that's A-OK. > > > I appreciate the clarification! > > > > On Sunday, October 9, 2016 at 12:28:56 PM UTC-7, vince wrote: >> >> On Sunday, October 9, 2016 at 10:10:00 AM UTC-7, Tim Phillips wrote: >>> >>> My understanding of how my Weewx on my Pi is: >>> >>> Weewx running as a daemon (service/background process). >>> >> >> almost certainly yes >> >> >>> Apache2 is the web server so a user can access the Weewx service >>> (daemon) from a browser on LAN/WAN (if port forwarded). >>> >> >> no. Apache does not talk to the weewx daemon at all. >> >> It listens on the port(s) you have it configured to listen on, commonly >> http (tcp/80), and makes available whatever data or programs apache is >> configured to permit (typically, just a document tree). Sometimes your web >> pages are executable (php typically) but most times not. Initially it's set >> up to just return data. >> >> The default weewx output from the default skins is just data....html >> files and image files. Other skins might have executable php content >> (saratoga templates to name one). Again, the apache configuration must be >> set up to permit php files to execute, and there is additional software >> you'd install to do that. There are a lot of apache-related packages. >> >> >> - Apache2 runs in the background and is the "gatekeeper" to the >>> services that request a browser-based information request. >>> >> >> not really. It's a daemon that listens on the port(s) it is configured >> for, and does what it's configured to do based on the apache config >> file(s). Again, usually it just provides a way to read files using a >> remote web browser kind of interface, from a well-defined directory on the >> filesystem. >> >> - Services get access *through *the Apache server to the >>> destination port it's assigned to. In Weewx's case it's "/weewx". >>> >>> >> no. Apache makes some files (in locations defined by the apache config >> files) on the pi accessible via http or https, assuming those files are >> accessible by the non-privileged account the apache daemon runs as. >> >> >>> BUT, if the port to Apache is 80, and that directs to Weewx, then how >>> would I set up multiple WAN access, say if I had a webcam service running >>> on the same Pi? >>> >>> >> Again, apache doesn't really 'direct' to weewx, it can make >> weewx-generated output files available, if weewx puts it in a place apache >> is configured to know about, and if the files are set with the right >> permissions so the apache daemon can read them. >> >> You would configure the webcam to accept incoming requests on another >> port typically, hopefully over https with a strong non-default password >> required to see the files. This seems to be what most of the IoT break-ins >> seem to be exploiting....folks who just go shields-down in a insecure >> vendor-default configuration. >> >> I'm not quite sure what you're asking about WAN vs. LAN access, but if >> you're a typical home user you likely have your LAN behind a gateway device >> that blocks all incoming WAN access, unless you forward particular ports >> through your firewall. >> >> Be very careful here. If you're asking the types of questions you're >> asking, I'd suggest doing it right might be a little above your >> understanding/expertise at this point in time. By far the safest thing to >> do is to permit 'no' incoming traffic WAN=>LAN even through port forwarding. >> >> >> >> -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
