Opened 8 years ago

Closed 8 years ago

#1665 closed task (fixed)

Add Confirmation Flow to LDAP Account Creation

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: SysAdmin Keywords: ldap


Due to spam accounts (see #1578) and related problems the LDAP account creation dialog has been disabled. This ticket tracks the task of upgrading the account creation to include a confirmation step.

Change History (13)

comment:1 by warmerdam, 8 years ago

Alex also suggests:

I just recalled something useful. It would be great if we could blacklist certain email domains. In particular yopmail and dayrep which are disposable email addresses (public readable, trashes all mail after 8 days) were used for many of the spam accounts recently. An email service like that is contradictory to being able to use email recover passwords when forgotten.

comment:2 by warmerdam, 8 years ago

OK, I end up incorporating Recaptcha instead of email validation. Hopefully this will be acceptable. It also excludes yopmail and dayrep, though I feel at least mildly uncomfortable about that.

comment:3 by warmerdam, 8 years ago

Resolution: fixed
Status: newclosed

comment:4 by wildintellect, 8 years ago

Sadly, it does not appear to be enough ldapsearch -H ldaps:// -b dc=osgeo,dc=org -x "(&(modifytimestamp>=20160501100000Z))" shows accounts made in the last day or so, not tons of accounts but they are mostly spam accounts. This may be a case of someone doing it by hand, though looking at the IP in the apache logs for the spam accounts, there is no clear single IPs or ranges.

I think we need to disable again, and try something else.

comment:5 by strk, 8 years ago

Resolution: fixed
Status: closedreopened

Reopening until the captcha is confirmed to help. Also, I think email confirmation would be better, delayed by 5 minutes as suggested bu Jorge would be good. See

comment:6 by strk, 8 years ago

Having found an extract of the apache logs I see there's no way to tell which user was created, due to all the data being in a POST payload. It would be helpful to fix this as well. It could be done by reading the name from PATH_INFO, for example (POST /cgi-bin/, or the script could implement logging internally (possibly better). Better file a new ticket for this ?

comment:7 by strk, 8 years ago

For the record: the user creation form is currently disabled -- see

comment:8 by strk, 8 years ago

The form is enabled again. There's an average of 5 users being created per hour. Do I understand correctly that no confirmation is ever required for specifying an email ? This is something that really needs to be fixed ASAP as we'd be otherwise attributing activities to unaware people (for example via Gogs and gravatar).

comment:9 by strk, 8 years ago

The form was disabled again, after confirming that almost all the users created during the active period (about 15) started spamming some hours later. We'd need (1) logging from the tool itself to document which user was supposedly created at which date (and maybe passing which tests), (2) ensuring email is valid and reachable (slowing registration at the same time).

Also, it would be nice to avoid a call to google for each form submission (currently done by the use of recaptcha).

comment:10 by strk, 8 years ago

Keywords: ldap added

I found a project which could be a starting point to refactor the registration management:

comment:11 by strk, 8 years ago

See also password reset script, which may be propedeutic: #1741

comment:12 by strk, 8 years ago

Ready for test:

(need a valid mantra to proceed, while in maintainance mode)

comment:13 by strk, 8 years ago

Resolution: fixed
Status: reopenedclosed

Deployed after further testing as

Note: See TracTickets for help on using tickets.