Pro sign-in link invalid for default HTTP(S) ports

[manish]

Hi,

The pro account sign-up email contains an invalid sign-in link.

https://subdomain.domain.tld:0/ep/account/sign-in?uid=N&tp=PWD

I have been trying EtherPad on the default HTTP port (80). Digging a
bit, I found that the full pro sub/super domain host string generation
logic does not check for the validity of the port number:

trunk/etherpad/src/etherpad/pro/pro_utils.js:
// domain, including port if necessary
function getFullProHost() {
var h = getFullProDomain();
var parts = request.host.split(':');
if (parts.length > 1) {
h += (':' + parts[1]);
}
return h;
}

function getFullSuperdomainHost() {
if (isProDomainRequest()) {
var h = getRequestSuperdomain()
var parts = request.host.split(':');
if (parts.length > 1) {
h += (':' + parts[1]);
}
return h;
} else {
return request.host;
}
}

I have tried my luck with the Scala code, but no luck so far.

Any ideas?

Manish Jhawar

[John McLear]

http://mclear.co.uk/2009/12/21/etherpad-ssl-https-pro-setup/

[Paul Winkler]

I'm having the same problem but I *want* to use SSL.
The problem is that there are links in various places with port 0 in
them.
Why port zero? How do I get rid of it?

Thanks.

- PW

On Apr 3, 10:40 am, John McLear <johnym...@gmail.com> wrote:
> http://mclear.co.uk/2009/12/21/etherpad-ssl-https-pro-setup/
>

--
Subscription settings: http://groups.google.com/group/etherpad-open-source-discuss/subscribe?hl=en

[Jeff Mitchell]

On 04/19/2010 01:00 PM, Paul Winkler wrote:
> I'm having the same problem but I *want* to use SSL.
> The problem is that there are links in various places with port 0 in
> them.
> Why port zero? How do I get rid of it?
>
> Thanks.
>
> - PW
>
> On Apr 3, 10:40 am, John McLear <johnym...@gmail.com> wrote:
>> http://mclear.co.uk/2009/12/21/etherpad-ssl-https-pro-setup/
>>
>> On Sat, Apr 3, 2010 at 6:38 AM, manish <jhawarman...@gmail.com> wrote:
>>> Hi,
>>
>>> The pro account sign-up email contains an invalid sign-in link.
>>
>>> https://subdomain.domain.tld:0/ep/account/sign-in?uid=N&tp=PWD
>>
>>> I have been trying EtherPad on the default HTTP port (80). Digging a
>>> bit, I found that the full pro sub/super domain host string generation
>>> logic does not check for the validity of the port number:

Stupid question: can you just fix your port number in your config file?

--Jeff

[Paul Winkler]

On Apr 19, 5:54 pm, Jeff Mitchell <mitch...@kde.org> wrote:
> On 04/19/2010 01:00 PM, Paul Winkler wrote:
> > I'm having the same problem but I *want* to use SSL.
> > The problem is that there are links in various places with port 0 in
> > them.
> > Why port zero? How do I get rid of it?
>

> Stupid question: can you just fix your port number in your config file?
>

Where would I do that? I don't see anywhere to configure the SSL port.
I'm running etherpad itself on port 9000, behind nginx running on
ports
80 and 443.

Everything works fine over HTTP, I just can't figure out how to avoid
the bogus port 0 in all generated HTTPS links.

I "fixed" the problem in mail invites by hardcoding my site's HTTPS
URL in
src/etherpad/pro/pro_accounts.js, but now I'm finding that lots of
other links are
bad so I'd like to tackle the root cause. If nobody knows the answer,
I'll just
keep poking around and see if I can trace things back further than
pro_utils.getFullProHost().
It might take me a while to get around to it though.


- PW

[Jeff Mitchell]

On 4/20/2010 10:31 AM, Paul Winkler wrote:
> On Apr 19, 5:54 pm, Jeff Mitchell <mitch...@kde.org> wrote:
>> On 04/19/2010 01:00 PM, Paul Winkler wrote:
>>> I'm having the same problem but I *want* to use SSL.
>>> The problem is that there are links in various places with port 0 in
>>> them.
>>> Why port zero? How do I get rid of it?
>>
>> Stupid question: can you just fix your port number in your config file?
>>
>
> Where would I do that? I don't see anywhere to configure the SSL port.
> I'm running etherpad itself on port 9000, behind nginx running on
> ports
> 80 and 443.
>
> Everything works fine over HTTP, I just can't figure out how to avoid
> the bogus port 0 in all generated HTTPS links.

Using the "hidePorts" option in your properties file? (see the example
properties file...)

--Jeff

[Paul Winkler]

Thanks Jeff. I tried adding "hidePorts = true" to etherpad/trunk/
etherpad/etc/etherpad.localdev-default.properties,
is that the right file?

But it doesn't seem to have any effect on this problem.
When I visit https://pro.my-etherpad-domain.org I get redirected to
port 0 like so:

GET / HTTP/1.1

Host: pro.etherplans.org

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9)
Gecko/20100402 Ubuntu/9.10 (karmic) Firefox/3.5.9

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
*;q=0.8

Accept-Language: en-us,en;q=0.8,fr;q=0.5,az;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Cookie: ...


HTTP/1.1 302 Found

Server: nginx/0.7.62

Date: Fri, 23 Apr 2010 18:47:09 GMT

Transfer-Encoding: chunked

Connection: keep-alive

Location: https://pro.etherplans.org:0/


If I disable "require HTTPs" (by tweaking the database directly since
I now can't acess the web UI at all),
and patch main.js to disable checkHTTPS(), then things work fine over
plain old HTTP.

Any other ideas?

>  signature.asc
> < 1KViewDownload

[Jeff Mitchell]

On 4/23/2010 3:37 PM, Paul Winkler wrote:
<snip>

I'm guessing one of two things: either your web server setup is bogus,
or your certificate store is bogus, or both.

I have found that doing https does not work well using https only on the
front-end (in your case nginx). Things work better if I set up https in
Etherpad as well, because Etherpad seems to have an expectation in
various places that if it's giving out https URLs it should be seeing
the requests coming in on its secure port, or something along those
lines -- I haven't really worked out why this is yet. The downside is
that depending on your cert, it may mean a bit of work.

I'm behind on creating a new install guide that would cover both of
these bits of info. I was supposed to do a full soup-to-nuts install
with a friend and was going to document every bit of it; he decided he
didn't have time so I have to find resources to do it alone (meaning
setting up wildcard DNS on some other domain, etc., since I want to test
it running properly).

(This can also serve as notice to those on this list: if someone else is
interested in doing this with me, that would be great. You have to have
a place to set it up and a willingness to do exactly what I tell you to
do, and nothing more, so that the steps are accurate. Contact me
off-list if this describes you.)

Anyways, back on topic: I can help you, but I need some info. Could you
please sanitize and post your Etherpad config file, the relevant parts
of your nginx setup (if you're not sure, include more, not less), and
information about your SSL certs (are they self-signed or from some
authority that Java implicitly trusts, etc.) and whether you've added
them to Etherpad's store?

Thanks,
Jeff

[Paul Winkler]

Jeff Mitchell wrote:
(snip)

> I have found that doing https does not work well using https only on the
> front-end (in your case nginx). Things work better if I set up https in
> Etherpad as well, because Etherpad seems to have an expectation in
> various places that if it's giving out https URLs it should be seeing
> the requests coming in on its secure port, or something along those

> lines -- I haven't really worked out why this is yet. (snip)

Thanks Jeff, that was the clue I needed.

At least for now, I've removed nginx from the picture and I'm just
running etherpad on ports 80 and 443.
This works fine; I just had to add sslKeyPassword and
sslStorePassword to my
etherpad.localdev-default.properties file.

I would still be interested in seeing docs on how to get SSL working
properly when behind proxy such as ningx or apache, but for now
this'll do.

- PW

[Jeff Mitchell]

Paul,

Below is my nginx config file for these sites and the include file it
references.

A few notes:

1) The places where you'd have to substitute IPs/hostnames/certs and the
like should be obvious. However, the 192.168.8.115 IP is real. I have
etherpad start on a fake local IP, then proxy to it. That way I can have
etherpad run on ports 80/443 where it seems to work best/easiest.

2) You can see in there where I have some access control for creating
new pads/sites (the site I run is publically accessible but I don't want
the public being able to do as they like with it). For some reason that
I have yet to sort out this doesn't quite work right -- the basic
authentication works, but then I get an infinite redirect. So I
currently comment that out very temporarily when a new team site or pad
is needed, then re-enable it.

Config file: http://dpaste.com/194220/
Include file: http://dpaste.com/194221/

--Jeff

[vortex]

Today I struggled above the same problem. After investigating a bit, I
found out that it can be fixed quite easily. My setup is similar to
yours, except that we are running Apache mod_proxy instead of ngix.

Edit src/etherpad/utils.js and find the methods httpsHost(h) and
httpHost(h). Comment out the whole if-conditions from those methods
and there won't be any ports anymore in any URLs.

Both should look like this:

function httpsHost(h) {
h = h.split(":")[0]; // strip any existing port
/*
if (appjet.config.listenSecurePort != "443") {
h = (h + ":" + appjet.config.listenSecurePort);
}*/
return h;
}

function httpHost(h) {
h = h.split(":")[0]; // strip any existing port
/*if (appjet.config.listenPort != "80") {
h = (h + ":" + appjet.config.listenPort);
}*/
return h;
}

Best regards,
Sebastian

>  signature.asc
> < 1 KBAnzeigenHerunterladen