2.5 KiB
2.5 KiB
| stage | group | info |
|---|---|---|
| Manage | Authentication and Authorization | To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments |
Spam protection and CAPTCHA
This guide provides an overview of how to add spam protection and CAPTCHA support to new areas of the GitLab application.
Add spam protection and CAPTCHA support to a new area
To add this support, you must implement the following areas as applicable:
- Model and Services: The basic prerequisite changes to the backend code which are required to add spam or CAPTCHA API and UI support for a feature which does not yet have support.
- REST API (Supported, documentation coming soon): The changes needed to add spam or CAPTCHA support to Grape REST API endpoints. Refer to the related REST API documentation.
- GraphQL API: The changes needed to add spam or CAPTCHA support to GraphQL mutations. Refer to the related GraphQL API documentation.
- Web UI: The various possible scenarios encountered when adding spam/CAPTCHA support to the web UI, depending on whether the UI is JavaScript API-based (Vue or plain JavaScript) or HTML-form (HAML) based.
You should also perform manual exploratory testing of the new feature. Refer to Exploratory testing for more information.
Spam-related model and API fields
Multiple levels of spam flagging determine how spam is handled. These levels are referenced in
Spam::SpamConstants,
and used various places in the application, such as
Spam::SpamActionService#perform_spam_service_check.
The possible values include:
BLOCK_USERDISALLOWCONDITIONAL_ALLOWOVERRIDE_VIA_ALLOW_POSSIBLE_SPAMALLOWNOOP