summaryrefslogtreecommitdiff
path: root/lib/gitlab/recaptcha.rb
Commit message (Collapse)AuthorAgeFilesLines
* Apply recaptcha API changes in 4.0Toon Claes2019-03-081-2/+2
| | | | | | | | | | In recaptcha 4.0.0 there was an API change: - `public_key` -> `site_key` - `private_key` -> secret_key See: https://github.com/ambethia/recaptcha/blob/master/CHANGELOG.md
* Enable frozen string for lib/gitlab/*.rbgfyoung2018-10-221-0/+2
|
* use Gitlab::UserSettings directly as a singleton instead of ↵Mario de la Ossa2018-02-021-6/+4
| | | | including/extending it
* `current_application_settings` belongs on `Gitlab::CurrentSettings`Sean McGivern2017-08-311-0/+2
| | | | | | | | | | | | | | | | The initializers including this were doing so at the top level, so every object loaded after them had a `current_application_settings` method. However, if someone had rack-attack enabled (which was loaded before these initializers), it would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't have that method. To fix this: 1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need `Object.new.current_application_settings` to work. 2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it like that in several places. 3. Change the initializers to use that new form.
* Use reCaptcha when an issue identified as spamJarka Kadlecova2017-02-071-0/+4
|
* reCAPTCHA is configurable through Admin Settings, no reload needed.Gabriel Mazetto2015-12-281-0/+14