Can't use accounts with .local emails
Good Morning,
I have an air gapped environment I'm trying to run PgAdmin4 in. I'm currently running 4.7, with the 4.7 docker image. When my users attempt to log in with LDAP, or if I try to create an account for someone, I get the following error:
The domain name
In this environment all emails are in a domain ending with .local. Is there any way to make PgAdmin4 allow email addressed with that naming? If not, is there a way to prevent it from populating the email field on successful LDAP login? If there isn't a way, can a way be added?
I'm having troubles tracking down where the error message comes from in the source, so I'm not sure how I could modify it.
Thanks, ~Bethany
Hi @countessellis, pgAdmin internally uses https://pypi.org/project/email-validator/ package which do not allow special use domain names listed here - https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. A workaround suggested is to remove the special domain using the below code:
import email_validator
email_validator.SPECIAL_USE_DOMAIN_NAMES.remove("local")
You can put this code in custom config_local.py or config_system.py file. Please read https://www.pgadmin.org/docs/pgadmin4/7.0/config_py.html#the-config-py-file for more details.
Thanks.
Thanks, that worked!
Having run into the same issue, I do not think pgadmin should validate an email address on login, exactly because of changes like this. An address that was valid in the past during registration might not be "valid" any more after an update and then users are locked out.
It would be wise to introduce a new config var ALLOW_SPECIAL_EMAIL_DOMAINS = [] as an array so that users do not need to add a code snippet and would work directly using env var.
I'm reopening this issue.
Hi @countessellis, pgAdmin internally uses https://pypi.org/project/email-validator/ package which do not allow special use domain names listed here - https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. A workaround suggested is to remove the special domain using the below code:
import email_validator email_validator.SPECIAL_USE_DOMAIN_NAMES.remove("local")You can put this code in custom
config_local.py or config_system.pyfile. Please read https://www.pgadmin.org/docs/pgadmin4/7.0/config_py.html#the-config-py-file for more details.Thanks.
This no longer works as of 8.11, or at least in my Docker environment I am getting a repetitive spam of:
'[email protected]' does not appear to be a valid email address. Please reset the PGADMIN_DEFAULT_EMAIL environment variable and try again.
I'm not sure why this decision has been made because some systems don't sit on a server with an FQDN, and I don't feel particularly comfortable with exposing something easily guessable such as example.com, or worst, to make use of a genuine registered FQDN.
How is this solved in 8.11 please so that we can continue to use pgAdmin?
Working fine.Verified on candidate build.
Working fine.Verified on candidate build.
@yogeshmahajan-1903
Please could you confirm how this works? I've tried setting in config_local.py with:
ALLOW_SPECIAL_EMAIL_DOMAINS = ['test.local']
And I have also tried setting as an environment variable in my Docker Compose file:
pgadmin:
image: docker.io/dpage/pgadmin4:8.12
restart: unless-stopped
environment:
- [email protected]
- PGADMIN_DEFAULT_PASSWORD=${DB_PASSWORD}
- PGADMIN_DISABLE_POSTFIX=True
- PGADMIN_CONFIG_ALLOW_SPECIAL_EMAIL_DOMAINS=['test.local']
volumes:
- ./config/pgadmin/config_local.py:/pgadmin4/config_local.py:rw,z
- ./config/pgadmin/servers.json:/pgadmin4/servers.json:rw,z
depends_on:
- database
Both approaches don't seem to work and I still get error messages in my console:
pgadmin | '[email protected]' does not appear to be a valid email address. Please reset the PGADMIN_DEFAULT_EMAIL environment variable and try again.
The documentation doesn't seem to reflect the new environment variable - https://www.pgadmin.org/docs/pgadmin4/latest/container_deployment.html
I have got the above working with this:
pgadmin:
image: docker.io/dpage/pgadmin4:8.12
restart: unless-stopped
environment:
- [email protected]
- PGADMIN_DEFAULT_PASSWORD=${DB_PASSWORD}
- PGADMIN_DISABLE_POSTFIX=True
- PGADMIN_CONFIG_ALLOW_SPECIAL_EMAIL_DOMAINS=['local']
volumes:
- ./config/pgadmin/servers.json:/pgadmin4/servers.json:rw,z
depends_on:
- database
This works for Docker, although it's a little confusing because the domain being used isn't local, that's the TLD. Rather the domain is test.local.
Given that the actual environment variable is named as ALLOW_SPECIAL_EMAIL_DOMAINS this suggests that it would be a list of FQDN, rather than the TLD. This is somewhat confusing from a users POV - at least from my testing whereby I would be expecting to input test.local for the domain, rather than local.
Hi @AlexWinder,
Yes I agree we should put up one example of how to use ALLOW_SPECIAL_EMAIL_DOMAINS.
The domains which are marked as special by email validator as per the standards are ["arpa", "invalid", "local", "localhost", "onion", "test"]. You can allow one or more from this list.
Thanks for clearing up @adityatoshniwal - though I believe that this environment variable would benefit from a better naming convention as per my comments above.
Thanks for implementing this change in any case, it's much welcome.
Thanks @adityatoshniwal for ALLOW_SPECIAL_EMAIL_DOMAINS, @AlexWinder for PGADMIN_CONFIG_ALLOW_SPECIAL_EMAIL_DOMAINS clarification... works nicely.
fwiw aside... I try to use @<random_domain>.local instead of @<random_domain>.com when a live domain isn't needed (test, air-gapped prod, etc.). Using .local is zero-cost risk avoidance... a simple security hedge. If a live domain owned by someone else is used, it creates undefined risk that most assumptively gloss over. (Those drive me batty, like clutter. 😊) Using .local removes the uncertainty at nil cost, has zero worry, saves brainpower needed to assess a likely silly, low-probability risk. With that in mind, when .local is blocked by validator defaults, it weakens posture by consequence of the validator, not by design of the service.
So adding ALLOW_SPECIAL_EMAIL_DOMAINS allows one to remove unnecessary concerns having possible risk despite assumptions otherwise.