When configuring a new shop without any presets, no user info set, we provide an email validation link (because email is not configured either). Whenever a non-standard port is used, _all emails_ should probably include the port as well.
This link does not work when running on non-standard ports, such as when you start a new docker instance, because the port is not included in the url.

The port should be included in the url, if it's not port 80, so that this link works.
That link gets populated using Meteor.absoluteUrl() (which gets its domain/port from the ROOT_URL environment variable). That decision was originally made because the external port is going to be dictated by the -p flag used in the Docker command that starts the container in production. And the app doesn't have access to that info from inside the container. That said, I don't think we can make any assumptions about ports there, so that's why I set it up to use the ROOT_URL (which all users should be setting in a production deployment and is the most reliable source for the correct domain/port on the outside of the container).
Considering that the person who deploys a production instance has access to the server, logs, and environment variables, do we need to enforce email verification here? Would it maybe be easier to treat this the same way as development and allow that default admin to be verified by default? I feel like it might be adding a little extra complication that doesn't necessarily add any additional security. In the unlikely event that someone gets access to the default admin credentials, you kind of already have a bigger problem that email verification doesn't fix.
There was an env variable REACTION_SECURE_DEFAULT_ADMIN introduced, which allows the admin to decide it the email needs to be verified or not. This means that the verification is now optional, which should address @jshimko proposal.
What's open is to confirm that the email link does include the port specified in ROOT_URL. Jumping right into that and testing in dev mode and for docker builds..
I can verify that for docker builds and in development mode the port is added to the verification link provided that ROOT_URL has defined it.
***************************************************
IMPORTANT! EMAIL VERIFICATION LINK
Email sending is not configured.
Go to the following URL to verify email: hpwgdbe3@localhost
http://tsp.dyn.projekt-und-partner.de:3000/#/verify-email/OLzrJJbwW_Bb7KcIz1hufcdH9GxdDX9C7j7zwl80Smw
***************************************************
But the verification itself does not seem to work. After navigating to the above link, the database still hasn't updated the verified field. Neither in Accounts.emails.$.verified nor in Users.emails.$.verified.
I realized that this is because the above link seems wrong. I don't know if this is because it's a hash-based URL, but it seems like the URL is a no-op (maybe it has to do with the react router not supporting hash-based URLs, I don't know)
The URL scheme that actually is working would be:
http://tsp.dyn.projekt-und-partner.de:3000/account/profile/verify?email=testing%40localhost
@aaronjudd I'll create a new ticket for that and vote for closing this one in favor of the newly created one: #3714
Most helpful comment
That link gets populated using
Meteor.absoluteUrl()(which gets its domain/port from theROOT_URLenvironment variable). That decision was originally made because the external port is going to be dictated by the-pflag used in the Docker command that starts the container in production. And the app doesn't have access to that info from inside the container. That said, I don't think we can make any assumptions about ports there, so that's why I set it up to use theROOT_URL(which all users should be setting in a production deployment and is the most reliable source for the correct domain/port on the outside of the container).Considering that the person who deploys a production instance has access to the server, logs, and environment variables, do we need to enforce email verification here? Would it maybe be easier to treat this the same way as development and allow that default admin to be verified by default? I feel like it might be adding a little extra complication that doesn't necessarily add any additional security. In the unlikely event that someone gets access to the default admin credentials, you kind of already have a bigger problem that email verification doesn't fix.