immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-02-05 00:30:57 +03:00
Code Issues 18 Packages Projects Releases 10 Wiki Activity

[BUG] email validation is too strict #912

New Issue
Closed
opened 2026-02-04 23:30:21 +03:00 by OVERLORD · 8 comments
OVERLORD commented 2026-02-04 23:30:21 +03:00
Owner
Copy Link

Originally created by @uhthomas on GitHub (Jun 5, 2023).

The bug

Emails are notoriously difficult to validate. It should simply check whether an @ is present, rather than trying to be too smart. The email admin@localhost is absolutely valid, and yet Immich will reject it.

{"statusCode":400,"message":["email must be an email"],"error":"Bad Request"}

The OS that Immich Server is running on

N/A

Version of Immich Server

v1.59.1

Version of Immich Mobile App

N/A

Platform with the issue

  • Server
  • Web
  • Mobile

Your docker-compose.yml content

N/A

Your .env content

N/A

Reproduction steps

N/A

Additional information

N/A

Originally created by @uhthomas on GitHub (Jun 5, 2023). ### The bug Emails are notoriously difficult to validate. It should simply check whether an `@` is present, rather than trying to be too smart. The email `admin@localhost` is absolutely valid, and yet Immich will reject it. ``` {"statusCode":400,"message":["email must be an email"],"error":"Bad Request"} ``` ### The OS that Immich Server is running on N/A ### Version of Immich Server v1.59.1 ### Version of Immich Mobile App N/A ### Platform with the issue - [X] Server - [X] Web - [ ] Mobile ### Your docker-compose.yml content ```YAML N/A ``` ### Your .env content ```Shell N/A ``` ### Reproduction steps ```bash N/A ``` ### Additional information N/A
OVERLORD commented 2026-02-04 23:30:28 +03:00
Author
Owner
Copy Link

@samip5 commented on GitHub (Jun 5, 2023):

While I agree with that, there may be an issue with oauth if it's not strict.

@samip5 commented on GitHub (Jun 5, 2023): While I agree with that, there may be an issue with oauth if it's not strict.
OVERLORD commented 2026-02-04 23:30:32 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jun 5, 2023):

I agree with @samip5. I think your email example is not valid. If you have something like user@localhost.com it would be valid

image

@alextran1502 commented on GitHub (Jun 5, 2023): I agree with @samip5. I think your email example is not valid. If you have something like `user@localhost.com` it would be valid ![image](https://github.com/immich-app/immich/assets/27055614/97e67930-1a22-49f5-8dc1-b6beeb080c43)
OVERLORD commented 2026-02-04 23:30:35 +03:00
Author
Owner
Copy Link

@uhthomas commented on GitHub (Jun 5, 2023):

@alextran1502 This is not correct. It is absolutely valid to use a hostname like that.

See http://ai/.

Therefore, an email like admin@ai will work. Immich should support this.

Further, locahost.com is not the same as localhost.

@uhthomas commented on GitHub (Jun 5, 2023): @alextran1502 This is not correct. It is absolutely valid to use a hostname like that. See http://ai/. Therefore, an email like `admin@ai` will work. Immich should support this. Further, `locahost.com` is not the same as `localhost`.
OVERLORD commented 2026-02-04 23:30:38 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jun 5, 2023):

This is the edge case we don't want to deal with since it might potentially complicate other OAuth providers 🤔. What do you think?

@alextran1502 commented on GitHub (Jun 5, 2023): This is the edge case we don't want to deal with since it might potentially complicate other OAuth providers 🤔. What do you think?
OVERLORD commented 2026-02-04 23:30:43 +03:00
Author
Owner
Copy Link

@uhthomas commented on GitHub (Jun 5, 2023):

I'm not really sure it's that much of an edge-case? An arbitrary restriction on valid email domains is not desirable, especially when it conflicts with valid domains. I don't envision any complications with oauth providers, as a domain localhost, a.localhost and a.b.c.localhost should all be treated equally regardless.

@uhthomas commented on GitHub (Jun 5, 2023): I'm not really sure it's that much of an edge-case? An arbitrary restriction on valid email domains is not desirable, especially when it conflicts with valid domains. I don't envision any complications with oauth providers, as a domain `localhost`, `a.localhost` and `a.b.c.localhost` should all be treated equally regardless.
OVERLORD commented 2026-02-04 23:30:47 +03:00
Author
Owner
Copy Link

@alextran1502 commented on GitHub (Jun 5, 2023):

@uhthomas if you are willing to open a PR for this, I will be willing to look at and merging if it helps solve this issue

@alextran1502 commented on GitHub (Jun 5, 2023): @uhthomas if you are willing to open a PR for this, I will be willing to look at and merging if it helps solve this issue
OVERLORD commented 2026-02-04 23:30:51 +03:00
Author
Owner
Copy Link

@uhthomas commented on GitHub (Jun 5, 2023):

Yep, would be happy to do so. Would you mind reopening the issue for tracking?

@uhthomas commented on GitHub (Jun 5, 2023): Yep, would be happy to do so. Would you mind reopening the issue for tracking?
OVERLORD commented 2026-02-04 23:31:01 +03:00
Author
Owner
Copy Link

@uhthomas commented on GitHub (Jun 5, 2023):

FWIW, it looks like the package class-validators depends on https://www.npmjs.com/package/validator for validation.

The relevant section suggests require_tld should be set to false.

isEmail(str [, options]) check if the string is an email.options is an object which defaults to { allow_display_name: false, require_display_name: false, allow_utf8_local_part: true, require_tld: true, allow_ip_domain: false, domain_specific_validation: false, blacklisted_chars: '', host_blacklist: [] }. If allow_display_name is set to true, the validator will also match Display Name . If require_display_name is set to true, the validator will reject strings without the format Display Name . If allow_utf8_local_part is set to false, the validator will not allow any non-English UTF8 character in email address' local part. If require_tld is set to false, email addresses without a TLD in their domain will also be matched. If ignore_max_length is set to true, the validator will not check for the standard max length of an email. If allow_ip_domain is set to true, the validator will allow IP addresses in the host part. If domain_specific_validation is true, some additional validation will be enabled, e.g. disallowing certain syntactically valid email addresses that are rejected by Gmail. If blacklisted_chars receives a string, then the validator will reject emails that include any of the characters in the string, in the name part. If host_blacklist is set to an array of strings and the part of the email after the @ symbol matches one of the strings defined in it, the validation fails. If host_whitelist is set to an array of strings and the part of the email after the @ symbol matches none of the strings defined in it, the validation fails.
@uhthomas commented on GitHub (Jun 5, 2023): FWIW, it looks like the package `class-validators` depends on https://www.npmjs.com/package/validator for validation. The relevant section suggests `require_tld` should be set to false. isEmail(str [, options]) | check if the string is an email.options is an object which defaults to { allow_display_name: false, require_display_name: false, allow_utf8_local_part: true, require_tld: true, allow_ip_domain: false, domain_specific_validation: false, blacklisted_chars: '', host_blacklist: [] }. If allow_display_name is set to true, the validator will also match Display Name <email-address>. If require_display_name is set to true, the validator will reject strings without the format Display Name <email-address>. If allow_utf8_local_part is set to false, the validator will not allow any non-English UTF8 character in email address' local part. If require_tld is set to false, email addresses without a TLD in their domain will also be matched. If ignore_max_length is set to true, the validator will not check for the standard max length of an email. If allow_ip_domain is set to true, the validator will allow IP addresses in the host part. If domain_specific_validation is true, some additional validation will be enabled, e.g. disallowing certain syntactically valid email addresses that are rejected by Gmail. If blacklisted_chars receives a string, then the validator will reject emails that include any of the characters in the string, in the name part. If host_blacklist is set to an array of strings and the part of the email after the @ symbol matches one of the strings defined in it, the validation fails. If host_whitelist is set to an array of strings and the part of the email after the @ symbol matches none of the strings defined in it, the validation fails. -- | --
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:translation
cli
date-time
documentation
external-library
format
good first issue
needs-answer
nice to have
sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#912
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?