Deployment options require {{ confirm_email_link }} configuration

[jcborras]

Apologies for asking here first should not be considered the proper place.

I've got a webapp deployed coupled with nginx, the later for handling https and serving static content. Nothing fancy the nginx conf boils down to:

server {
    listen 443 ssl ;
    server_name myapp.local; 

    location /static {
      root /home/www/myapp/static ;
    }

    location / {
      proxy_pass http://myapp.local:5000/ ;
    }
}

The problem is that every single account confirmation email redirects to:

1. http:// and not the secure version
2. the local service host
3. the port number...
   I've tried fiddling with the SERVER_NAME Flask config var or even hardcoded parameters in Flask.run() method but someone Flask-User always manages to find the hostname and port where the app is running....

So the question is: what is the easiest way of modifying the confirm_mail_link variable in the confirm_email_link so that it points where I want to?

Thanks in advance.

[neurosnap]

Greetings!

Having not worked with SSL and the proxy_pass in NGINX please forgive my ignorance.

confirm_email_link is created here: https://github.com/lingthio/Flask-User/blob/master/flask_user/views.py#L688

Flask-User does not generate the domain portion of the URL, Flask does, therefore unless Flask-User effects Flask's url_for function then this is a problem with Flask.

Here is the url_for documentation: http://flask.pocoo.org/docs/0.10/api/#flask.url_for
_external is set to True when generating the confirm_email_link. As you have said, adjusting SERVER_NAME does not help, which is curious.

I found this StackOverflow post that may be relevant:
http://stackoverflow.com/questions/25962224/running-a-flask-application-at-a-url-that-is-not-the-domain-root

In which the above SO links to this Flask snippet:
http://flask.pocoo.org/snippets/35/

If that doesn't help, what Python version are you running? If you don't use SSL and proxy_pass in NGINX, do you get the same problem?

[jcborras]

Closing the issue since it definitely does not belong here. I'll comment once I've gone through the links you mention.
Lots of thanks.

[jcborras]

Becomes quickly a rabbit hole.

Flask's url_for() does a fine job within the browser scope since it accepts the _external parameter which by default is True hence all generated URLs will not start with schema://hostname:port/: the browser concatenates things, all links just work and everything is fine.... until we leave the browser realm.

Enter Flask-User confirmation emails with their confirm_email_link variable:

confirm_email_link = url_for('user.confirm_email', token=token, _external=True)

url_for(..., _external=True) will make the url to contain some schema://hostname:port/ heading string. Sensible thing to do since that link will work outside the browser scope. Where does Flask-User get the schema, hostname and port from? From Flask of course, which does not retrieve it from the SERVER_NAME config var but from the given runtime parameters given at Flask.run(host=..., port=...) (actually from Werkzeug's LocalStack which would explain bypassing SERVER_NAME).

The whole paragraph above is a sensible choice until.... you hit some particular deployment scenario where, for instance, the Flask web application is not visible outside the server realm (i.e. nginx serving only HTTPS on 443 and handling traffic from the internet to the webapp listening confortable on localhost:someport). Since only nginx knows all those bits of information... kaboom.

Where do I pin it on? Nowhere. Flask does what it should and so does Flask-User. Sure changing the Flask-User line above (and any other similar occurrence like in a password reset situation?) to take actual global URL info (from the config file for instance) and cat it together will do the trick.

But that's something I'll do in my imminent fork....

If my solution is pretty I'll submit a p.r.

Eric, again, thanks a lot for putting some of your time on this.

[jcborras]

Fixed the issue and created a pull-request to summarize.
It's kind of large since it affects 8 files (including setup.py for version clarification).
No intention to push it whatsoever. Repo owners decision will be fully accepted.
#64