mirror of
https://github.com/opensolutions/ViMbAdmin.git
synced 2026-04-26 00:36:00 +03:00
[GH-ISSUE #223] Private/Internal Domains Fully Broken #175
Labels
No labels
bug
feature
feature
improvement
improvement
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ViMbAdmin-opensolutions#175
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
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?
Originally created by @rootwyrm on GitHub (Feb 4, 2017).
Original GitHub issue: https://github.com/opensolutions/ViMbAdmin/issues/223
As @barryo wrote here: https://groups.google.com/forum/#!searchin/vimbadmin-discuss/hostname%7Csort:relevance/vimbadmin-discuss/wWj1ykYT8Hs/D3oLPD7nN3EJ
There is a means to disable the hostname validation, but this is a manual solution which only works for adding domains. The issue I am having is that I have an initial setup domain which is deliberately not a 'valid' TLD, and all other domains will also be 'invalid' TLDs.
However, two problems arise. One, this suggested fix is two years old and no longer even slightly correct. Two, the call to Zend_Validate_Hostname has now been obfuscated or buried somewhere else. Even grepping the whole thing does not reveal the new location. It's only found in vendor/zendframework.
This means that it is completely impossible to use an internal/private domain in a valid fashion with ViMbAdmin currently with no workaround available at all.
@PhrozenByte commented on GitHub (Feb 5, 2017):
Creating a
pilas.gurudomain and adding atest@pilas.gurumailbox works just fine for me (ViMbAdmin 3.0.15), this is also true for the domainexampletld(i.e. without a dot)...@rootwyrm commented on GitHub (Feb 5, 2017):
guruis a valid TLD; seevendor/zendframework/zendframework1/library/Zend/Validate/Hostname.php@ 516.exampletldis most likely treated as a bare hostname, not domain.Set up a new install and try to configure the administrator as 'admin@vimbadmin.pvt' - this will fail unless you add
pvtto the array in Hostname.php mentioned above.@PhrozenByte commented on GitHub (Feb 5, 2017):
Ah, so this issue is about adding administrators only. Yeah, I can reproduce this issue. However, adding a new
vimbadmin.pvtdomain and adding both mailboxes and aliases works just fine, its really just about adding administrators.The validation actually happens in the OSS-Framework and is used multiple times in ViMbAdmin. I don't think such strict validation is necessary at all, ultimately the only thing that matters is whether the administrator's username/email is in the database or not. Thus I recommend simply removing the
EmailAddressvalidator @barryo (either in OSS-Framework or by replacing all occurrences in ViMbAdmin).#edit: Please note that the
EmailAddressvalidator is also used to validate thealt_emailandcc_welcome_emailfields when adding new mailboxes. I'm not 100% sure whether we should remove them or not.@rootwyrm commented on GitHub (Feb 5, 2017):
@PhrozenByte that's something I missed there; you're absolutely right. The administrator login shouldn't be getting validated at all! (IMNSHO, using a 'garbage' address that can't possibly be found if someone misconfigures VRFY is best here for security reasons if nothing else.)
However, I'd argue that removing the validator from everything is probably a bit overkill. I was thinking more along the lines of providing a toggle in
application.inifor users to enable/disable validation for additional domains. And since the admin logins are already decoupled via theadmintable, removing even the check if it's email format. Seems to me removing just that check would instantly solve the immediate problem at setup.Edit; Just for giggles, I tested it. It's not quite as clean as I hoped. The login page obviously needs to do validation. So it would need to either check if the user exists in the admin table first or provide some other way to say 'hey, use the admin user.'
@barryo commented on GitHub (May 16, 2020):
Allowing any domain was fixed some time ago I believe (certainly works for me) - this is domains and mailboxes.
I don't see any reason to remove validation of a proper email from the admin user element. Sorry, using made up domains / emails here just seems beyond excessive. If you need that level of security, put ViMbAdmin on an internal / protected network.