reset password emails do not use the website URL

[carandraug]

When resetting a password, an email is sent to the user with a URL. That URL uses the internal name, port, and protocol instead of the public one and not what's defined in CODALAB_SITE_DOMAIN.

On my specific case, CodaLab is behind a proxy server. The email sent to the users uses the internal hostname which is not publicly available. The issue appears to be at the django-allauth app, a dependency of codalab. This seems to already be reported and fixed upstream:

https://github.com/pennersr/django-allauth/pull/3081
https://github.com/pennersr/django-allauth/pull/3108

From the dates in the django-allauth releases, it appears that version 0.51.0 has fixed the issue. However, codalab has a locked requirement on version 0.35.0 with a comment that seems to suggest that CodaLab has (or had) a patched version of django-allauth so I don't know whether we can just change the version without introducing other issues.

[bbearce]

Hi carandraug,

Thanks for reporting this. May I ask if you have the latest code? I assume yes but I ask as we recently checked in code that attempts to address this and we thought it was all set to go.

If you have that code then can you look into this workflow:

What I'm doing is changing the CODALAB_SITE_DOMAIN and checking to see if in the database in the Sites table if you can see a site (your example site) that correctly records the .env file's value for CODALAB_SITE_DOMAIN. In the picture using docker-compose up -d to adjust the changes allows me to click the password reset button and see in my email the different site domains as well. I want to make sure I understand you correctly so if that is not happening, there could be something wrong with the setup or code. Can you reproduce this workflow:

1. Click change password and generate email.
2. Rather than change the password just change the CODALAB_SITE_DOMAIN variable in .env and run docker-compose up -d
3. Then click change password again for your user and see if the email shows the change. Also check that in the database, the Domain name records the change as well.

We can look into django-allauth but want to be sure it's not something else first as this doesn't quite happen for us. Do you think that since we run the platform in it's native design without a proxy-server that that somehow changes something? Either way, the current code should be able to edit this field. You can also manually change it in the database, but I know that's not ideal.

Keep us posted. Don't hesitate to follow up as we have a test instance we can use to test things out.