empty domain in generated token send via email

[cguentherTUChemnitz]

The token, which is send via email looks as follows:

http:///index.php?action=resetbytoken&token=3vUCAGq...

As you can see, the FQDN is missing. I am running the service behind an ssl-terminating reverse proxy with the following config: https://github.com/zokradonh/kopano-docker/blob/a630007059cf4c0ec52dc1d713bd8d52f172bde2/docker-compose.yml-example#L53-L88

even when i add

IS_BEHIND_PROXY="https://${FQDN}/password-reset/"

No the crafted link inside the email does not contain any domain. I already have checked, that FQDN is properly set.

What do i missing here?

[tiredofit]

I too run behind a SSL terminating proxy. (nginx) On our production systems our environment variable is IS_BEHIND_PROXY=true

Give that a try?

[cguentherTUChemnitz]

Oh very interesting. When is use IS_BEHIND_PROXY=true than the service crashes and i get:

Parse error: syntax error, unexpected 'URL' (T_STRING) in /www/ssp/conf/config.inc.local.php on line 211

It seems the wrong line is uncommented. The state of the config.inc.local.php in my container is:

 Reset URL (if behind a reverse proxy)
#$reset_url = $_SERVER['HTTP_X_FORWARDED_PROTO'] . "://" . $_SERVER['HTTP_HOST'];

So we seem to have some problem in the config patching. Nevertheless, when i correct this manually to

# Reset URL (if behind a reverse proxy)
$reset_url = $_SERVER['HTTP_X_FORWARDED_PROTO'] . "://" . $_SERVER['HTTP_HOST'];

I need a possibility to modify this from the outer world. I see 2 problems here:

1. The HTTP_X_FORWARDED_PROTO is not set correctly. It contains http instead of https (which is not a problem, because i have automatic forwarding).
2. The more severe problem is, that we host this in a subfolder instead of a subdomain in the kopano-stack. So we need something that resolves to https://kopano.demo/password-reset for the reset_url.

PS: oh man you are doing your fixes faster, than i capture my logs for the answer.

[tiredofit]

#2 found the culprit due to some earlier changes. I've put a quick fix in place with the new tag of 3.0.1 but will clean this up further in coming days, relying on a line number is bound to cause problems again in future.

[tiredofit]

Proper fix complete - reissuing tag 3.0.1

[cguentherTUChemnitz]

You are faster with fixing, than my gathering my logs and updating my comment^^ So those two problems remains:

I need a possibility to modify this from the outer world. I see 2 problems here:

1. The HTTP_X_FORWARDED_PROTO is not set correctly. It contains http instead of https (which is not a problem, because i have automatic forwarding).
2. The more severe problem is, that we host this in a subfolder instead of a subdomain in the kopano-stack. So we need something that resolves to https://kopano.demo/password-reset for the reset_url.

[tiredofit]

First coffee of the day and before my inbox goes mad usually gets me going pretty quickly :) For 1 - I'll take a peek at our configuration and see - We could expand on the IS_BEHIND_PROXY variable and either add a new variable to replace http with https, although we run in quite a similar fashion and its' been approximately 2 years since I've really looked at our implementation. We've actually moved on to using FusionDirectory and LemonLDAP for our password reset functionality, but that would be far too much for the Kopano stack you are putting together. Give me a few hours on this one.

For 2 - I don't believe we can solve it without a bunch of hacking to the container. On the web proxy, setting up an alias and then forwarding it to the container would certainly work, but we will run into the password tool issuing a bad url when sending the token by mail. Again, we can hack away at it - and I believe it would be a matter of adding an environment variable (and hacking at the source) to override the URL. I can do that, it may take a bit longer as I'm juggling a large team project right now, and more than likely would be submit it upstream to the ltb-selfservice-password project instead of keeping it unique to just this image. Let me think about it further.

[tiredofit]

I've been thinking about this today and coming up against this in a few other images that I haven't released. I will push a new image tomorrow for you with a potential fix.

[cguentherTUChemnitz]

Thank you for your great support.

[aderbique]

@tiredofit I tried the new version of latest and am still seeing an empty url. Is this something I can simply hardcode for the time being?

Digest: sha256:ce06e1e9ee8b09f3d669b9ca9ef5ad287047739e3c2bd3bbbf23a3f02c671f1e

Example Problem: http:///index.php?action=resetbytoken&token=3vUCA

[tiredofit]

@aderbique I am not seeing it on my end but others are so somethings a bit off. Can you do me a favour on your running container edit /etc/nginx/conf.d/default.conf and place server_name yoururl.domain.com; on line 3, save the file, and then execute nginx -s reload ? Lets see if they are relying on _SERVER variables.

[aderbique]

Wow that's a fast response. So I actually got it working. After digging around, looks like you just need to uncomment line 212 of install/assets/ssp/config.inc.php.template

#$reset_url = $_SERVER['HTTP_X_FORWARDED_PROTO'] . "://" . $_SERVER['HTTP_HOST']; to $reset_url = $_SERVER['HTTP_X_FORWARDED_PROTO'] . "://" . $_SERVER['HTTP_HOST'];

Then set environment variables HTTP_X_FORWARDED_PROTO=http(s) HTTP_HOST=example.com

[aderbique]

@tiredofit Adding a server name did not seem to change anything. Also, I should probably edit my last comment. For some reason, the HTTP_HOST part is being filled out, but HTTP_X_FORWARDED_PROTO is still blank.

CLIENT -> SERVER: ://example.com:8080?action=resetbytoken&token=3vUCAHPLxl

[tiredofit]

Thanks for that. What about if you didn't change the config.inc.php.template at all and used the env var IS_BEHIND_PROXY=true - That should sort it as well.

[aderbique]

Thanks for that. What about if you didn't change the config.inc.php.template at all and used the env var IS_BEHIND_PROXY=true - That should sort it as well.

I am using IS_BEHIND_PROXY=true

Take a look at my previous message about HTTP_X_FORWARDED_PROTO

[tiredofit]

OK. Sorry - didn't see that you were already using it. Whats the reverse proxy you are using? I'm using a modified but close to upstream jwilder/nginx-proxy.

I'm going to reach out to my developers and see if they've made any changes to the source code which is why I'm not seeing it.

[aderbique]

OK. Sorry - didn't see that you were already using it. Whats the reverse proxy you are using? I'm using a modified but close to upstream jwilder/nginx-proxy.

Currently not using one. But from what I read, Reset URL (if behind a reverse proxy) #$reset_url = $_SERVER['HTTP_X_FORWARDED_PROTO'] . "://" . $_SERVER['HTTP_HOST'];

it appears that if I set IS_BEHIND_PROXY=true then that will force the the http://example.com, etc.

In the future, I plan to use Traefik to handle reverse proxy pass.

Also, thanks for the help!

[tiredofit]

Hmm, now I am questioning my own image here. I just took a peek at the source, it's not modified to hardcode the url anywhere, however what I did find that is interesting is in my config.inc.php that the reset_url variable was still commented out yet it's working providing me the url I was visiting to get the token as well as using the correct protocol. I'm going to have to wait until the middle of the night to take down this service and examine it further as I still have a boat load of users online.

Good choice on the traefik, that is my eventual plan as well, I just need to find some time to alter my cloudflare companion container that auto provisions CNAMEs to work under traefik and we'll make the switch.

[cguentherTUChemnitz]

Is there any insight to this topic in the meantime?

[tiredofit]

Still nothing, I've been swamped with work. My original thought is that it was related to nginx configuration to which I was going to dynamically add server_name domain.example.com; which theoretically should be able to determine the host via _SERVER variables. It fell flat. I may need some assistance on this one while I am stuck in a hectic professional project.

[cguentherTUChemnitz]

The kopano stack developer did implement an approach to init config.php values based on environment variables passed into the container. Would this approach helps also here? https://github.com/zokradonh/kopano-docker/pull/112/files

[daMihe]

Hi, having a similar issue (did it get to work). I want that the generated URL does contain a folder, i.e. "https://my.host.name/resetpw/". I've configured a reverse proxy to redirect the requests correctly and can fill the form. However the url inside the reset mail is malformed. Why not just let the administrator set the URL inside a variable?

[nickadams675]

@tiredofit Curious if you have had time to delve deeper into this issue? Thanks!