Issue Details (XML | Word | Printable)

Key: JRA-3619
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Jeff Turner [Atlassian]
Votes: 25
Watchers: 10
Operations

If you were logged in you would be able to see more operations.
JIRA

Validate email addresses of users who sign up

Created: 20/Apr/04 08:45 PM   Updated: 29/Jul/08 10:10 AM
Component/s: User Management
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Issue Links:
Blocker
 
Reference

Participants: Andy Jefferson, Anton Mazkovoi [Atlassian], Brett Adam, Erin Spiceland, Ernest Koe, Jeff Turner [Atlassian], Lars Torunski, Martin Bravenboer, Nick Menere [Atlassian], Reid Sayre, Rob Lanphier, Ryan Lee, Sam Berlin and Scott Lawrence
Since last comment: 10 weeks, 6 days ago
Support reference count: 4
Labels:


 Description  « Hide
JIRA should have an option to verify that a user owns the email address they claim to have, when signing up for an account.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Scott Lawrence added a comment - 19/Jul/04 08:34 AM

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.


Jeff Turner [Atlassian] added a comment - 24/Jan/05 06:51 PM
We'll look into this for 3.2 (no promises).

Lars Torunski added a comment - 24/Jan/05 11:39 PM
There should be an option: "Exclude emails from validation" = "*.atlassian.com"

E.g. a regular expression excludes the employees of a company from validation.


Jeff Turner [Atlassian] added a comment - 26/Jan/05 10:40 PM
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.


Martin Bravenboer added a comment - 24/Sep/06 01:17 AM
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.


Ryan Lee added a comment - 04/Dec/06 12:09 PM
Seconded as a spammer obstacle.

Reid Sayre added a comment - 15/Dec/06 08:43 AM
In the last few weeks, we have been hit with two different spam attackers, multiple occurrences of one of them.
  • Someone registers a userid and then adds a spam comment to multiple issues. We revoke the user as soon as we can, but this one has hit three separate times, with three separate new userids. The specified e-mail address was at Yahoo. We don't know if the e-mail address is valid. Apparently, Yahoo does not bounce invalid mail addresses.
  • Someone else used someone else's email address and generated a userid. The real owner of the email address notified us that he did not create the userid.

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:

  • Disable letting the newly registered user set his or her own password, forcing the user to obtain his or her password via a valid e-mail address.
  • Force a "pending" state. The e-mail that sends the password should also contain a unique "enablement" URL that must be called in order to get out of "pending" state.
  • Force a password change on first use.
  • Go back through the whole process if the user changes the domain of his e-mail address, and force an immediate logout..
  • Log appropriate information so that perhaps an IP address range could be blocked via firewall for repeat offenders.

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.


Brett Adam added a comment - 15/Dec/06 09:18 AM
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.


Nick Menere [Atlassian] added a comment - 17/Dec/06 10:19 PM
Hi guys,
Just to let you know we are taking the spam issue seriously and we want to address it sooner rather than latter and are aiming for a permanent solution for 3.8. We haven't fully spec'ed it out yet but I am imagining some sort of user validation in tandem with some smart form captcha.

Cheers,
Nick


Reid Sayre added a comment - 18/Dec/06 08:36 AM
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.

Sam Berlin added a comment - 18/Dec/06 11:29 AM
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.

Nick Menere [Atlassian] added a comment - 18/Dec/06 05:33 PM
Please refer the tools located at - http://confluence.atlassian.com/display/JIRASPAM/Deleting+JIRA+comment+spam
These remove all instances of spam.

Andy Jefferson added a comment - 14/Jan/07 03:12 AM
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.

Reid Sayre added a comment - 29/Jan/07 01:51 PM
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:

  • a robot runs the "sign-up" process
  • another (or the same) robot then either creates a new issue or comments on an existing issue via e-mail within a few seconds.
  • perhaps a different robot interacts with JIRA via html or the SOAP interface to add inappropriate content to a JIRA deployment.

I believe the solution must contain:

  • CAPTCHA (see wikipedia) technology on the signup to stop (if possible) robots
  • User does not specify his own password, but JIRA generates one and sends to e-mail address.
  • Force password change on first interaction
  • User can't do anything until he or she logs in once.
  • log enough information in an easy to find place so that IP addresses can be blocked if spammer gets through shields.
  • Each of these needs to be optional depending on the JIRA deployment owner.

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.


Ernest Koe added a comment - 23/Jul/07 04:08 PM
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.

Anton Mazkovoi [Atlassian] added a comment - 24/Jul/07 05:03 AM
Ernest,

As far as I know the CAPTCHA on Signup introduced in JIRA 3.8:
http://confluence.atlassian.com/display/JIRA/JIRA+3.8+Release+Notes#JIRA3.8ReleaseNotes-captcha
helped with stopping SPAM.

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,
Anton


Reid Sayre added a comment - 24/Jul/07 08:16 AM
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.


Anton Mazkovoi [Atlassian] added a comment - 24/Jul/07 11:40 PM
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,
Anton


Rob Lanphier added a comment - 24/Dec/07 12:04 AM
This should not only be at signup, but should revalidate anytime the user changes the email address.

Erin Spiceland added a comment - 29/Jul/08 10:10 AM
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.