Coldsweat accessible from other devices

passiomatic / coldsweat

Web RSS aggregator and reader compatible with the Fever API

MIT License

145 stars 21 forks source link

Coldsweat accessible from other devices #77

Closed SkyCrawl closed 9 years ago

SkyCrawl commented 9 years ago

Thank you very much for coldsweat. It should get rid of a lot of problems for me :).

One issue though: when people (e.g. me) want to use it as an aggregator for multiple devices and run it on a network server, coldsweat should bind its service with the 0.0.0.0 IP address.

commands.py httpd = make_server('localhost', options.port, cascade_app)

The above line of code should not hardcode localhost (which translates into 127.0.0.1 - the loopback address only accessible from THAT machine). This should probably be another option of python sweat.py serve :).

passiomatic commented 9 years ago

Oh, I wasn't aware of the 0.0.0.0 address. Do you think there would be any drawback to bind to 0.0.0.0 by default instead of localhost?

SkyCrawl commented 9 years ago

I think so. Some people may not want to expose their machines to "public connections" on some networks :). Don't get me wrong - localhost is the better default and AFAIK everyone prefers it. However, it must not be hardcoded so that Coldsweat can be used remotely to synchronize devices, just like the Home page says it can. I think a command line option is a must :). EDIT: you could also add an option to Coldsweat's configuration if a command line option is not convenient for you.

passiomatic commented 9 years ago

you could also add an option to Coldsweat's configuration if a command line option is not convenient for you.

At least for now I prefer a command line option since one can already set the port via command line so it makes sense to have an option to bind to 0.0.0.0 too.

That said, what about a -0 command like option in the next release?

SkyCrawl commented 9 years ago

I have no intention of forcing you a particular solution but personally, I wouldn't add an option like that because of its unclear (and possibly ambiguous) nature. A "number option" like this doesn't specify its purpose and might lead someone to think -1 is also viable. The way I see it, it would be best to:

define a "letter option" (e.g. -r) with no value, in which case it is a "switch"
and speaking of switches, --allow-remote-access is a very good example of one that clearly states its purpose, uses common practices, improves source code clarity, reduces the chance of allowing public access by mistake and also makes itself far more visible to potential users/consumers :).

passiomatic commented 9 years ago

...and speaking of switches, --allow-remote-access is a very good example of one that clearly states its purpose

Makes perfect sense. I've implemented it in the refactor branch. Thank you.