|
We'll look into this for 3.2 (no promises).
There should be an option: "Exclude emails from validation" = "*.atlassian.com"
E.g. a regular expression excludes the employees of a company from validation. Perhaps also a flag on the user object, indicating whether the user email address has been validated.
Then one could have rules for granting permissions - if (email == atlassian.com and validated) then group = jira-developers. JIRA is currently getting a more popular target of spam in comments. It's a matter of time until spam users will be created, which will lead to spam issues as well. So this issue is rather important.
Moreover, if spammers can register automatically (usually with invalid email addresses) then JIRA-10236 will no longer be sufficient and captcha's will be necessary for registered users as well. Email validation would prevent this. In the last few weeks, we have been hit with two different spam attackers, multiple occurrences of one of them.
It is not realistic for us to make registration admin driven, and as noted above, adding this kind of function as a plugin is not really possible, so anything that happens here needs to be in the base code, probably controlled by a global property. I would like to see the following option built-in to the system, not a plug-in:
So far, this would reduce spam users. While you are in the user object, I would like to see a column some where in the user table that keeps the date that the registration was activated, and the last login date. Reid's comments and requests are spot-on, IMHO.
It's not possible for us to manually admin every user that requests an account - we're running JIRA in support of a large open source community user base (>7,000 and growing by a few hundred each week). Automation is the only viable answer. Hi guys,
Just to let you know we are taking the spam issue seriously Cheers, Hopefully, you can get this before 3.8. This one has been open for 2-1/2 years after all. I do not remember how long it has been since I signed up on an e-mail system that did not have some kind of confirmation.
We are being hit by spam pretty regularly too. Validating user emails would be very useful in limiting spam. Other options such as a CAPTCHA are good. However, in order to eradicate spam after it's accidentally hit, we also need a "delete as spam" button to fully delete the comment (including from the history), all other comments from that user, and blacklist the user. Alternately, comments could remain in the history, but all links could have a NOFOLLOW attribute added to the href.
Please refer the tools located at - http://confluence.atlassian.com/display/JIRASPAM/Deleting+JIRA+comment+spam
These remove all instances of spam. The "comment" tools are fine, but sadly spammers also now create issues. Can the JSP be improved to deal with that too please?
Better still would be a version of JIRA that does at least attempt to prevent it in the first place. Other web systems I use have had this for maybe 2 years. You have said earlier in this issue that you expect to have a solution by 3.8. Could we have a preview of that solution?
And here is the high level problem:
I believe the solution must contain:
I know it's probably impossible to stop all SPAM, but there are known ways to slow them down, and these shields need to be integrated into JIRA or at least to provide enough easy interfaces to help. any update on this? I'd like legit users to submit issues to a public-facing jira, If new users do not validate their accounts, they shouldn't be able to post issues.
Ernest,
As far as I know the CAPTCHA on Signup introduced in JIRA 3.8: At the moment, as this feature is not scheduled, I do not have an implementation date. May I ask if the CAPTCHA solution did not help in your case? Cheers, Actually, shortly after CAPTCHA appeared in JIRA, folks stopped spamming us (via that channel) even though we did not go to the new version immediately. Thanks for that.
However, that does not reduce the need to verify e-mail addresses. When you are trying to support companies that have a need to keep some things private from those outside the company, there is a need to be sure that when a person asserts that his e-mail address is "joe@abc-company.com" that joe really has an address at that company. At most places that I register an e-mail address nowadays, they check to be sure I own that address by not fully registering until I have received an e-mail and acknowledged it via some long unique key value (usually hidden in the response URL). In the case of JIRA, a real easy way to do that is not not let the user assign his own password, and it should be easy to do that and control it via a global configuration option. And if the e-mail address is changed by the user, a password change or some other acknowledgement should be forced. Thanks for your feedback!
As I mentioned in my previous comment, this is not currently scheduled. However, your comments will be very useful when we get to this. Cheers, This should not only be at signup, but should revalidate anytime the user changes the email address.
Just dropping by to voice my support for this feature. We're using JIRA 3.12.3 Enterprise with a Commercial license and would love to see email validation implemented.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I think this is an important feature for a publically-available Jira instance.
Nothing elaborate is needed; just have Jira send mail to the address given by the user, with a unigue (and hard-to-predict) URL that the user must follow to complete the account setup.