Whenever I create a new account It asks for email, user name and etc but It takes the same credentials in the respective fields that I have used for previous user creation and I think drupal doesn't allow to use same email for 2 or more different people.
I think it's storing on local but there is no use of it.

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Bug because this is a regression in privacy from previous versions of Drupal (Drupal 7).
Issue priority Major because this issue goes against general privacy expectations from an end-user standpoint.
Prioritized changes The main goal of this issue is usability. Having a previous user’s “private” email or username displayed to any following user who happens to access user/register on a given machine is counterintuitive and violates reasonable privacy expectations.

Issue fork drupal-2409107

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jeet09’s picture

Issue summary: View changes
FileSize
42.39 KB
YesCT’s picture

Issue tags: -#SprintWeekend2015 #user module +SprintWeekend2015

Thank you for opening this issue and attaching the screenshot.

The tag for the sprint, according to https://groups.drupal.org/node/447258 should be SprintWeekend2015 (no #).
Also, tags should be separated by comma, not a space.
In this case the component is find, we dont want a new tag #user module.

---

Please embed the screenshots into the issue summary.
The browser plugin from http://dreditor.org is what some contributors use to make that easier to do.

idebr’s picture

Title: User Registration Issue with existing credentials » Users can register with existing credentials
Category: Support request » Bug report

I updated the issue title to describe the issue described in the issue summary.

YesCT’s picture

Status: Active » Closed (cannot reproduce)

I pulled my 8.0.x to make sure I had the latest.
I installed.
I am not able to create any account using an email already used by a user.
I am not able to create any account using a username already used by a user.

Is your problem that the form fields at admin/people/create are prefilled with already used values, .... but the form errors ok, or is the form submitting ok?

user/register
is also having errors nicely when submitting the form with a username (or an email) that is already in use by a user.

YesCT’s picture

Status: Closed (cannot reproduce) » Active
Issue tags: +Needs usability review

hmm.
logging out, and using the url
user/register
submitting, and then again
user/register
I do get the form pre-filled with values I have previously used. but it errors fine if I try to resubmit the form with same values.

I think this is fine.

note admin/people/create is not pre-filling (if I am logged in as admin and using the page over and over)

jeet09’s picture

sometimes same browser is shared by 2 or 3 users and if one user is registering and another user comes up and open registration, the form values are already filled with previous user registered values any way drupal won't allow to use same email/username but I think it's not good.

RavindraSingh’s picture

As per user experience it should be fixed.

Let me give you an example. If there is a D8 drupal site is getting used by the educational institutes, And the same system is getting using by staff and students. is that case it should not show the last email id registered from the system(Browser) is visible for the next one.

We should fix it.

mglaman’s picture

After some digging, it is a browser data attribute being set on the form.

    // For non-admin users, populate the form fields using data from the
    // browser.
    if (!$admin) {
      $form['#attributes']['data-user-info-from-browser'] = TRUE;
    }

cgit link

When this line is commented out, the reported issue does not happen. Found this change notice when I did a Google search of the data attribute - https://www.drupal.org/node/2243627

alimac’s picture

YesCT’s picture

in drupal 8

when I do a ag (like grep but better)
ag data-user-info-from-browser

I get:

core/misc/form.js
179:      var $forms = $('[data-user-info-from-browser]').once('user-info-from-browser');

core/modules/comment/src/CommentForm.php
91:      $form['#attributes']['data-user-info-from-browser'] = TRUE;

core/modules/contact/src/MessageForm.php
113:      $form['#attributes']['data-user-info-from-browser'] = TRUE;

core/modules/user/src/RegisterForm.php
48:      $form['#attributes']['data-user-info-from-browser'] = TRUE;

core/modules/user/src/Tests/UserCreateTest.php
77:    $this->assertNoRaw('data-user-info-from-browser', 'Ensure form attribute, data-user-info-from-browser, does not exist.');
mglaman’s picture

mglaman’s picture

shaktik’s picture

Status: Active » Closed (works as designed)

I pulled my 8.0.x

admin/people/create
user/register
I'm not able to create any account using an email already used by a user.
I'm not able to create any account using a username already used by a user.

i think its working fine.

David_Rothstein’s picture

Title: Users can register with existing credentials » Drupal should not prepopulate the user register form with the email address of the last person who registered using the same web browser
Priority: Normal » Major
Status: Closed (works as designed) » Active

Retitling to be clear about what the issue is, and bumping to major to evaluate the potential privacy concerns. (I wouldn't call this critical really, since browsers do remember email addresses in other ways typically, but it seems very unexpected from a privacy perspective that if you go to a public computer, register for an account on a Drupal site, close the browser when you're done... the next person who comes along sees your private email address staring them in the face when they load the form.)

Bojhan’s picture

Issue tags: -Needs usability review
David_Rothstein’s picture

Title: Drupal should not prepopulate the user register form with the email address of the last person who registered using the same web browser » Drupal should not prepopulate the user register form with the email address and username of the last person who registered using the same web browser

Adjusting title - the email address is the worst part but populating it with the last person's username is wrong too.

nod_’s picture

Those info and this behavior used to be inside cookies with a 365 days expiration. Now it's in localStorage with no expiration date.

As you can see in the related issue, breaking this behavior was considered a bug. I'm fine with it, just get rid of drupal.form library and the data attribute in the register form and we'll be done with it.

phillamb168’s picture

This is a triage at the Los Angeles Sprints. @cilefen and I did the triage.

The issue summary is up-to-date but could be rewritten to improve legibility.

The issue can be reproduced by registering on a given D8 site (e.g., http://d8.dev/user/register), entering a username and email address, submitting the form, and then reloading the user/register page. Clearing local browser data removes the preloaded data, however.

#749748: Contact, register and comment forms do not prefill with user info from browser was the issue that introduced this bug.

This issue was marked as Major by an experienced contributor in comment #14 and we agree with the assessment. Normal issues have “isolated impact”. This issue will occur on all browsers, and there is a privacy impact.

xjm’s picture

(Saving proposed issue credit for discussion and triage participants at LA.)

cilefen’s picture

Status: Active » Needs review
FileSize
787 bytes
mgifford’s picture

Re-uploading patch for the bots.

cilefen’s picture

Title: Drupal should not prepopulate the user register form with the email address and username of the last person who registered using the same web browser » Do not prepopulate the user register form with the email address and username of the last person who registered using the same web browser
prasad_gogate’s picture

@prasad_gogate looking into this issue

prasad_gogate’s picture

Issue tags: +drupalconasia2016, +Triaged for D8 major current state

Issue is not replicate.
Tried to created users with the user registration form
Steps

  • 1. Navigate to - admin/people/create
  • 2. Add user
  • 3. Save.
  • 4. click add another user
  • 5. Populated next form does not show the previous added user.

Version tested - 8.1.0-dev

prasad_gogate’s picture

Issue tags: -Triaged for D8 major current state

The issue is not yet triaged as a current major hence un-tagging

cilefen’s picture

I think this issue refers to self-registration. Can you please try again?

cilefen’s picture

And, this is a bug so you should test on 8.0.x also to be sure.

xjm’s picture

@cilefen: Yep, @prasad_gogate, @nagwani, and I untagged the issue because it was accidentally the wrong tag, but we figured we were missing a step to reproduce the issue properly given comments from @David_Rothstein and yourself above. @nagwani was working on trying to reproduce the issue in 8.0.x as of when it was filed but not sure if that got done among all the other triage work. :) Thanks!

xjm’s picture

(Updating issue credit for the major triage.)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Shamsher_Alam’s picture

Status: Needs review » Needs work

I am facing the same issue. When the user registers form and clicks again on registration, still show laster user register detail. i can reproduce this issue on latest Drupal 8 release.

Shamsher_Alam’s picture

Status: Needs work » Needs review

#21 worked for me.

Shamsher_Alam’s picture

Status: Needs review » Reviewed & tested by the community

#21 worked.

Adam Neutrik’s picture

#21 worked. Awesome work here! I bow my thanks.

Shamsher_Alam’s picture

alexpott’s picture

Should we be making a general decision about this behaviour? We use the same feature in comments and contact forms for anonymous users. If you submit a contact form on a site I['m not sure I'd expect the site to dump my email address into local storage on that computer.

alexpott’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs product manager review

I think this needs a product manager review to decide if the behaviour of storing user input indefinitely on a computer for anonymous users is desired.

alexpott’s picture

Shamsher_Alam’s picture

Status: Needs review » Reviewed & tested by the community

Working fine.

Rob C’s picture

Status: Reviewed & tested by the community » Needs review

And lets set that back to needs review for the product manager. Thanks.

@alexpott "Reuse comment.module's anonymous cookie information"

Did some work on cookies last couple months:
- Contact and comment indeed set cookies in this way that contain the name and e-mail (homepage). (search for 'user_cookie_save' in D7)

This maybe should be an option/additional param or something, these cookies are now always set and the only way to stop it is clone the submit function and drop the line that sets the cookie. I had to clone the submit and remove the cookie cause of gdpr.

(and gdpr is 1 but what about eprivacy next year, these cookies contain data that should not be stored like this, or at least - not without consent) (i vote to just remove them completely, taking into account all upcoming changes to privacy, storing data, etc).

My 5 cents: we should not store anything like this. Cause 'desired': not by me, it is actually a hurdle now to fix it for all my visitors... I disabled contact and do not use comment, switched it all for a simple form, wasted some nice private time on this.

hindsight: we should test these in the future, cause the eprivacy amendment already existed back in 2009 and nobody tested if the issue had to conform to any law i guess?

(Side-note: think we need a cookie api...)

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

AmolB’s picture

User mglaman's comment worked for me.

Added the code in form_alter function:

$form['#attributes']['data-user-info-from-browser'] = FALSE;

And it worked.

Thanks mglaman

cilefen’s picture

Issue tags: +Security improvements
eelkeblok’s picture

The patch seems pretty straight-forward, and I think it is pretty universally agreed that this is undesirable behaviour. Does it make sense to just merge this? Does it need a test to make sure no one comes up with this again?

Although it does raise questions whether prefilling this information is a good idea at all, I think that question is not as nuanced for the registration form than for the comment form.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

mkolar’s picture

Status: Needs review » Reviewed & tested by the community

Using for already some time on our project, I guess this is ready to be merged.

larowlan’s picture

Status: Reviewed & tested by the community » Needs review

This still needs product manage review, I'll ping some folks

Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs product manager review

I think this is fine. The only negative side effect I can think of is manual UI testing will be harder because you will need to enter credentials manually. But that is an edge case and normal operation security improvements should not be held by that.

alexpott’s picture

@Gábor Hojtsy should we create issues for the other places this is used. I think the same holds true for anonymously commenting.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

I still feel that this not really a fix. We're still storing the data in local storage. This only means that it is not displayed if someone visits the user create form. We need to remove the ability to store personal information in local storage. We shouldn't be saving it for anonymous comments or anonymous use of the contact form. At least the user creation form doesn't usually have the form.js javascript on it because if it did then that would also save these details. But all I'd have to do make this happen is add a text with summary field to the User entity via the UI and allow it to be filled in on the registration form.

nod_’s picture

for that we can use the Clear-Site-Data header, to empty localstorage, serviceworkers, cookies, etc. I'm using that in the PWA module to clear things on login/logout. To me core should use that header to nuke everything on user logout.

What I did is that on login I clear all the storages (localstorage, serviceworkers, indexdb), and on logout I clear storage and cookies.

alexpott’s picture

@nod_ I think this is different. I think we should never be storing this stuff in local storage. For the Clear-Site-Data header to work you need to log out. This stuff is recorded even if you never log in.

nod_’s picture

Status: Needs work » Needs review
FileSize
5.88 KB

so something like this?

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

DonAtt’s picture

Re-rolled patch #58 for 9.4.x

Also removed this part from the test:

     // Test that browser autocomplete behavior does not occur.
+    // @todo just getting rid of this one? 
     $this->assertNoRaw('data-user-info-from-browser');

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
FileSize
158 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

DonAtt’s picture

Nitin shrivastava’s picture

Try to Fix CCF errors.

Austin986’s picture

I found this issue is still active in D10.0.9
What is the point to keep previous email and user name in register form?

Any patch or fix for D10 ?

idimopoulos made their first commit to this issue’s fork.

idimopoulos’s picture

Rerolled patch 66 for 10.1.x and 11.x.
However, I should note that this is a blind reroll. Did not check if there are any changes in core that might affect this.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.