pop3proxy doesn't accept the hostname:portno notation
for the -l (i.e. uiPort) flag. I did'nt like everybody on our
LAN being able to read my mail using a webbrowser, so
I wrote the attached path, this allows -l localhost:8880
Unless I'm misunderstanding something, this is exactly
what the html_ui_allow_remote_connections setting is for...?
Thanks for the patch anyway - there's nothing wrong with
being able to specify the address that way whether
html_ui_allow_remote_connections solves your problem
or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You bring up a very good point, Wolfgang. Your patch plugs one hole, but
someone can still access your mail via http://<yourip>:8880 (or
whatever port you happen to be listening on). This is a problem, and I think
the solution is to implement http auth... We can't just reject connections
that don't originate from localhost, because someone really might want
to use another computer to access the pop3proxy ui.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Richie, thanks for the hint, I didn't know about the new
html_ui_allow_remote_connections option, because I didn't
read through docs and sources again after doing a new
checkout. Using the Option parsing helper functions was
simply done by looking for symmetry.
Tim: assuming that localhost is resolved locally to 127.0.0.1,
AFIK only local processes using the loopback interface can
bind to the port, when somesthing listens on
localhost:<something>. That's exactly what I need, when
everything (mail client, browser, pop3proxy) runs on the very
same machine.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Richie - do you still think that this is worth including, even
with all the other security stuff that's there now? If the
patch does work (does it?), then it certainly seems very
simple.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's worth including if it still works against the current code.
I'll give it a look as soon as I can. I think I've had a brief look
before and the code had changed under it, but I could be
thinking of something else.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code has changed beyond all recognition, so the
patch is no longer meaningful. The UI port comes from
options["html_ui", "port"], which is of type PORT - that
would need to change to something that allowed an
optional server component. Everything that used that
option (quite a few things) would need to allow for the
new format. Given html_ui_allow_remote_connections
and our support for http-auth, I don't think it's worth
the time and the potential introduction of bugs to add
this feature.
Tony, I'll pass this back to you for the final say.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=311771
Forgot the checkmark, as usual. arrggg.
pop3proxy.diff
Logged In: YES
user_id=311771
ahem. Make that ".. this allows -u localhost:8880", of course
Logged In: YES
user_id=85414
Unless I'm misunderstanding something, this is exactly
what the html_ui_allow_remote_connections setting is for...?
Thanks for the patch anyway - there's nothing wrong with
being able to specify the address that way whether
html_ui_allow_remote_connections solves your problem
or not.
Logged In: YES
user_id=645698
You bring up a very good point, Wolfgang. Your patch plugs one hole, but
someone can still access your mail via http://<yourip>:8880 (or
whatever port you happen to be listening on). This is a problem, and I think
the solution is to implement http auth... We can't just reject connections
that don't originate from localhost, because someone really might want
to use another computer to access the pop3proxy ui.
Logged In: YES
user_id=311771
Richie, thanks for the hint, I didn't know about the new
html_ui_allow_remote_connections option, because I didn't
read through docs and sources again after doing a new
checkout. Using the Option parsing helper functions was
simply done by looking for symmetry.
Tim: assuming that localhost is resolved locally to 127.0.0.1,
AFIK only local processes using the loopback interface can
bind to the port, when somesthing listens on
localhost:<something>. That's exactly what I need, when
everything (mail client, browser, pop3proxy) runs on the very
same machine.
Logged In: YES
user_id=552329
Richie - do you still think that this is worth including, even
with all the other security stuff that's there now? If the
patch does work (does it?), then it certainly seems very
simple.
Logged In: YES
user_id=85414
It's worth including if it still works against the current code.
I'll give it a look as soon as I can. I think I've had a brief look
before and the code had changed under it, but I could be
thinking of something else.
Logged In: YES
user_id=85414
The code has changed beyond all recognition, so the
patch is no longer meaningful. The UI port comes from
options["html_ui", "port"], which is of type PORT - that
would need to change to something that allowed an
optional server component. Everything that used that
option (quite a few things) would need to allow for the
new format. Given html_ui_allow_remote_connections
and our support for http-auth, I don't think it's worth
the time and the potential introduction of bugs to add
this feature.
Tony, I'll pass this back to you for the final say.
Logged In: YES
user_id=552329
Sounds fine to me; leaving it closed.