Opened 5 years ago

Closed 5 years ago

#1665 closed task (fixed)

Add Confirmation Flow to LDAP Account Creation

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone:
Component: Systems Admin 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 Changed 5 years ago by warmerdam

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 Changed 5 years ago by warmerdam

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 Changed 5 years ago by warmerdam

Resolution: fixed
Status: newclosed

comment:4 Changed 5 years ago by wildintellect

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 Changed 5 years ago by strk

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 Changed 5 years ago by strk

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 Changed 5 years ago by strk

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

comment:8 Changed 5 years ago by strk

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 Changed 5 years ago by strk

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 Changed 5 years ago by strk

Keywords: ldap added

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

comment:11 Changed 5 years ago by strk

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

comment:12 Changed 5 years ago by strk

Ready for test:

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

comment:13 Changed 5 years ago by strk

Resolution: fixed
Status: reopenedclosed

Deployed after further testing as

Note: See TracTickets for help on using tickets.