First, I really thing IHM deserves praise for its "keep it simple" philosophy. Cospend and Spliit are both nice solutions, but they also come with restrictions compared to IHM due to their sheer size. For me, simpler tools have a great value : easier and cheaper to deploy and integrate with other existing tools, smaller attack surface...
I set up a public-facing instance intended to serve me, family and friends.
After a few hours, 2 fraudulent projects had been created, resulting in 2 "Project Creation" spam-mails sent. I disabled the instance. Allowing my server+domain to send spam will result in my domain being quickly banned from most email MTAs. That would be catastrophic.
I'm wondering about the best security practices to run an instance, without impacting convenience too much.
ALLOW_PUBLIC_PROJECT_CREATION=False Prevent bots 100%, but not convenient. + sharing admin password seems weird (friends can see other friends projects without invite, etc...).
ENABLE_CAPTCHA=True Prevent bots, probably not 100%, but also not super convenient. (Adds 1 painful step when creating project).
VHost requiring http user Auth. Prevent bots 100%, but seems it doesn't work with apps like MoneyBuster. Only web + require typing auth = not convenient.
Using a VHost with secret path. ex : https://ihatemoney.example.com/[ThisIsASharedSecret]/ . Works with MoneyBuster/QRCodes, probably prevents most of the bots (until Secret is found). URL impossible to memorize/type. To me, this is the nicest solution for now.
My idea to solve the issue :
Adding an config PROJECT_CREATION_EMAIL_VALIDATE=/path/to/script Config to have a script to validate emails (using whitelist, regex, LDAP, whatever). IMHO, this would be the easiest way to admin the list of "friends and family". No spam could be sent to "unknown" emails, and it's very flexible.
Or the same thing, but stored as a Whitelist in DB, that can be edited in the admin page. Less flexible. Requires more UI in the Admin Page.
Note that both are compatible.
This would result in :
no password/secret to know or type
Simple URL
Worse case of spambot = one of your friend/family receive an undue "Project Creation" email, you can act upon (ban IP, delete project, etc...)
Are there other/better ideas to address this issue ?
I can create the PR if you maintainers think it is worth. The change in code seem small to me.
Would it have some chances to get merged ?
Hello everyone, and thanks for this great tool !
First, I really thing IHM deserves praise for its "keep it simple" philosophy. Cospend and Spliit are both nice solutions, but they also come with restrictions compared to IHM due to their sheer size. For me, simpler tools have a great value : easier and cheaper to deploy and integrate with other existing tools, smaller attack surface...
I set up a public-facing instance intended to serve me, family and friends. After a few hours, 2 fraudulent projects had been created, resulting in 2 "Project Creation" spam-mails sent. I disabled the instance. Allowing my server+domain to send spam will result in my domain being quickly banned from most email MTAs. That would be catastrophic.
I'm wondering about the best security practices to run an instance, without impacting convenience too much.
ALLOW_PUBLIC_PROJECT_CREATION=FalsePrevent bots 100%, but not convenient. + sharing admin password seems weird (friends can see other friends projects without invite, etc...).ENABLE_CAPTCHA=TruePrevent bots, probably not 100%, but also not super convenient. (Adds 1 painful step when creating project).https://ihatemoney.example.com/[ThisIsASharedSecret]/. Works with MoneyBuster/QRCodes, probably prevents most of the bots (until Secret is found). URL impossible to memorize/type. To me, this is the nicest solution for now.My idea to solve the issue :
PROJECT_CREATION_EMAIL_VALIDATE=/path/to/scriptConfig to have a script to validate emails (using whitelist, regex, LDAP, whatever). IMHO, this would be the easiest way to admin the list of "friends and family". No spam could be sent to "unknown" emails, and it's very flexible.This would result in :
Are there other/better ideas to address this issue ?
I can create the PR if you maintainers think it is worth. The change in code seem small to me. Would it have some chances to get merged ?