Registration does not check pending_registrations collection for existence of the user name about bottle-cork

[equalogix]

I found a better and more obvious solution for the work around. Before calling the registration method in the Bottle/app, I do a find_one for the username in the pending_registrations collection. If it returns None, I then call the registration method. This step should be included in the registration method itself.

Given the low likelihood of the occurrence of this situation it may be preferable to simply try the update of the pending_registrations collection and then handle the duplicate key error if it occurs.

[FedericoCeratto]

Thanks for the feedback @equalogix
Unfortunately handling registrations have some tricky tradeoffs, as the registration method can be exposed to spam robots & co that can try to register large numbers of common names.
If you block duplicate registrations legitimate users can be prevented from registering by bots. Also, users might lose the first email or want to switch to a different email address before validating the registration.
Either the registration or the registration-validation have to work as "first comes first serve" to get a login. The latter seems safer as it requires a working email address.

[equalogix]

Federico, thank you for the quick reply.

I see your perspective, and all your points are valid. In terms of spam bots, I think there are more effective ways of dealing with the problem. The issue is that these measures are still required since with the current design a spam bot could still overload your db with pending registrations. One feature that you may want to consider would be adding is a TTL (time to live) index on the pending_registrations, such that records will be deleted after say 24 hours.

I think you are absolutely right when you say there are many trade-offs. In a Utopian world, the package would be agnostic in terms of these trade-offs and it would be up to the app designer to structure the app in way that is optimal for its specific needs. But we do not live in a Utopian world.

Nick

[FedericoCeratto]

_purge_expired_registrations does what you are asking for - the default time value is 96 hours - but it's not being run automatically (and maybe it should?).

the package would be agnostic in terms of these trade-offs and it would be up to the app designer to structure the app in way that is optimal for its specific needs

That's what you've done with find_one on pending_registrations - maybe it's a matter of documenting this use-cases. (contributions are welcome :) )