Commit Graph

123 Commits

Author SHA1 Message Date
Gerhard Schlager 8bdbefe0e0
FIX: Logout could fail due to cached user (#17325)
Logging out failed when the current user was cached by an instance of `Auth::DefaultCurrentUserProvider` and `#log_off_user` was called on a different instance of that class.

Co-authored-by: Sam <sam.saffron@gmail.com>
2022-07-04 17:01:19 +02:00
Jarek Radosz 1a5dbbf430
FIX: Correctly handle invalid auth cookies (#16995)
Previously it would blow up on invalid utf byte sequences. This was a source of spec flakiness.
2022-06-07 13:00:25 +02:00
Sam 616de83232
FIX: avoid concurrent usage of AR models (#16596)
Flagged by the truffle team at: https://meta.discourse.org/t/thread-unsafe-current-user-usage-in-auth-defaultcurrentuserprovider/225671

This usage of AR is unsafe currently, as AR models are not safe for concurrent usage

Introduces a new query potentially every minute which should be acceptable.
2022-05-03 08:50:56 +10:00
David Taylor 1551eaab01
FIX: Do not error when json-serialized cookies are used (#16522)
We intend to switch to the `:json` serializer, which will stringify all keys. However, we need a clean revert path. This commit ensures that our `_t` cookie handling works with both marshal (the current default) and json (the new default) serialization.
2022-04-20 19:15:40 +01:00
Rafael dos Santos Silva 1203121ac1
PERF: Throttle updates to API key last_used_at (#16390)
Co-authored-by: David Taylor <david@taylorhq.com>
2022-04-06 11:01:52 -03:00
David Taylor 4f06c24a57
DEV: Do not log API key scope and/or source-ip mismatches (#15423)
Using an incorrectly-scoped API key is something which should be fixed by the client - no need to log errors on the server-side.
2021-12-29 12:22:21 +00:00
Osama Sayegh b86127ad12
FEATURE: Apply rate limits per user instead of IP for trusted users (#14706)
Currently, Discourse rate limits all incoming requests by the IP address they
originate from regardless of the user making the request. This can be
frustrating if there are multiple users using Discourse simultaneously while
sharing the same IP address (e.g. employees in an office).

This commit implements a new feature to make Discourse apply rate limits by
user id rather than IP address for users at or higher than the configured trust
level (1 is the default).

For example, let's say a Discourse instance is configured to allow 200 requests
per minute per IP address, and we have 10 users at trust level 4 using
Discourse simultaneously from the same IP address. Before this feature, the 10
users could only make a total of 200 requests per minute before they got rate
limited. But with the new feature, each user is allowed to make 200 requests
per minute because the rate limits are applied on user id rather than the IP
address.

The minimum trust level for applying user-id-based rate limits can be
configured by the `skip_per_ip_rate_limit_trust_level` global setting. The
default is 1, but it can be changed by either adding the
`DISCOURSE_SKIP_PER_IP_RATE_LIMIT_TRUST_LEVEL` environment variable with the
desired value to your `app.yml`, or changing the setting's value in the
`discourse.conf` file.

Requests made with API keys are still rate limited by IP address and the
relevant global settings that control API keys rate limits.

Before this commit, Discourse's auth cookie (`_t`) was simply a 32 characters
string that Discourse used to lookup the current user from the database and the
cookie contained no additional information about the user. However, we had to
change the cookie content in this commit so we could identify the user from the
cookie without making a database query before the rate limits logic and avoid
introducing a bottleneck on busy sites.

Besides the 32 characters auth token, the cookie now includes the user id,
trust level and the cookie's generation date, and we encrypt/sign the cookie to
prevent tampering.

Internal ticket number: t54739.
2021-11-17 23:27:30 +03:00
Daniel Waterworth e7c0bbb9c0
DEV: Let's always give a drop_from param to deprecate (#14901)
So that we know when deprecations can be removed in the future.
2021-11-12 08:52:59 -06:00
Osama Sayegh 70fa67a9e1
FIX: Don't leak unhashed user API keys to redis (#14682)
User API keys (not the same thing as admin API keys) are currently
leaked to redis when rate limits are applied to them since redis is the
backend for rate limits in Discourse and the API keys are included in
the redis keys that are used to track usage of user API keys in the last
24 hours.

This commit stops the leak by using a SHA-256 representation of the user
API key instead of the key itself to form the redis key.

We don't need to manually delete the existing redis keys that contain
unhashed user API keys because they're not long-lived and will be
automatically deleted within 48 hours after this commit is deployed to
your Discourse instance.
2021-10-21 19:43:26 +03:00
David Taylor 4134173bbf
FEATURE: Add global admin api key rate limiter (#12527) 2021-06-03 10:52:43 +01:00
Martin Brennan 5f7bef6d20
FEATURE: Add email_encoded parameter to accept inbound base64 encoded emails (#12947)
We have found when receiving and posting inbound emails to the handle_mail route, it is better to POST the payload as a base64 encoded string to avoid strange encoding issues. This introduces a new param of `email_encoded` and maintains the legacy param of email, showing a deprecation warning. Eventually the old param of `email` will be dropped and the new one `email_encoded` will be the only way to handle_mail.
2021-05-06 12:59:52 +10:00
David Taylor 1cec333f48 REFACTOR: Introduce RouteMatcher class
This consolidates logic used to match routes in ApiKey, UserApiKey and DefaultCurrentUserProvider. This reduces duplicated logic, and will allow UserApiKeysScope to easily re-use the parameter matching logic from ApiKeyScope
2020-10-19 10:40:55 +01:00
David Taylor 1ba9b34b03
DEV: Move UserApiKey scopes to dedicated table (#10704)
This has no functional impact yet, but it is the first step in adding more granular scopes to UserApiKeys
2020-09-29 10:57:48 +01:00
Sam Saffron 44fba9463b
FEATURE: Add support for not persistent sessions
In some cases Discourse admins may opt for sessions not to persist when a
browser is closed.

This is particularly useful in healthcare and education settings where
computers are shared among multiple workers.

By default `persistent_sessions` site setting is enabled, to opt out you
must disable the site setting.
2020-09-11 15:11:24 +10:00
David Taylor 629ee5494d
FEATURE: Allow plugins to register parameter-based API routes (#10505)
Example usage:

```
add_api_parameter_route(
  method: :get,
  route: "users#bookmarks",
  format: :ics
)
```
2020-08-24 10:24:52 +01:00
Guo Xiang Tan 94fced2133
FIX: Handle PG readonly mode in `Auth::DefaultCurrentUserProvider`.
Avoid writing to the DB when PG is in readonly mode.
2020-07-21 13:44:05 +08:00
Roman Rizzi f13ec11c64
FEATURE: Add scopes to API keys (#9844)
* Added scopes UI

* Create scopes when creating a new API key

* Show scopes on the API key show route

* Apply scopes on API requests

* Extend scopes from plugins

* Add missing scopes. A mapping can be associated with multiple controller actions

* Only send scopes if the use global key option is disabled. Use the discourse plugin registry to add new scopes

* Add not null validations and index for api_key_id

* Annotate model

* DEV: Move default mappings to ApiKeyScope

* Remove unused attribute and improve UI for existing keys

* Support multiple parameters separated by a comma
2020-07-16 15:51:24 -03:00
Guo Xiang Tan d3c972c30c FIX: Rescue from readonly errors when looking up auth tokens.
Since this is rare, we don't want to check for
`Discourse.pg_readonly_mode?` on every request since we have to reach
for Redis. Instead, just rescue the error here.
2020-06-04 09:12:49 +08:00
David Taylor ff331e845a
DEV: Prevent 'previous definition' warnings for PARAMETER_API_PATTERNS 2020-05-13 12:54:28 +01:00
David Taylor 0344ad14c1
FIX: Add missing rss routes to parameter api whitelist 2020-05-12 16:08:35 +01:00
David Taylor 6230f5c554
FEATURE: Allow parameter authentication for UserApiKeys (#9742)
This refactors default_current_user_provider in a few ways:
- Introduce a generic `api_parameter_allowed?` method which checks for whitelisted routes/formats
- Only read the api_key parameter on allowed routes. It is now completely ignored on other routes (previously it would raise a 403)
- Start reading user_api_key parameter on allowed routes
- Refactor tests as end-end integration tests

A plugin API for PARAMETER_API_PATTERNS will be added soon
2020-05-12 13:35:36 +01:00
Martin Brennan fa572d3a7a
DEV: Remove all code referencing at_desktop bookmark reminders (#9650)
We have found no need for these reminder types, so we are removing the code for them.
2020-05-06 15:22:43 +10:00
Jeff Wong e3590d4ead
FEATURE: add user_session_refreshed trigger (#9412)
Trigger an event for plugins to consume when a user session is refreshed.

This allows external auth to be notified about account activity, and be
able to take action such as use oauth refresh tokens to keep oauth
tokens valid.
2020-04-14 09:32:24 -07:00
Dan Ungureanu 0653750fbf
FEATURE: Hash user API keys in the database (#9344)
The 'key' column will be dropped in a future commit.
2020-04-07 16:42:52 +03:00
Blake Erickson d04ba4b3b2
DEPRECATION: Remove support for api creds in query params (#9106)
* DEPRECATION: Remove support for api creds in query params

This commit removes support for api credentials in query params except
for a few whitelisted routes like rss/json feeds and the handle_mail
route.

Several tests were written to valid these changes, but the bulk of the
spec changes are just switching them over to use header based auth so
that they will pass without changing what they were actually testing.

Original commit that notified admins this change was coming was created
over 3 months ago: 2db2003187

* fix tests

* Also allow iCalendar feeds

Co-authored-by: Rafael dos Santos Silva <xfalcox@gmail.com>
2020-04-06 16:55:44 -06:00
Sam Saffron 25f1f23288
FEATURE: Stricter rules for user presence
Previously we would consider a user "present" and "last seen" if the
browser window was visible.

This has many edge cases, you could be considered present and around for
days just by having a window open and no screensaver on.

Instead we now also check that you either clicked, transitioned around app
or scrolled the page in the last minute in combination with window
visibility

This will lead to more reliable notifications via email and reduce load of
message bus for cases where a user walks away from the terminal
2020-03-26 17:36:52 +11:00
Jarek Radosz e950471c0f
DEV: Replace User.unstage and User#unstage API with User#unstage! (#8906)
* DEV: Replace User.unstage and User#unstage API with User#unstage!

Quoting @SamSaffron:

> User.unstage mixes concerns of both unstaging users and updating params which is fragile/surprising.
> u.unstage destroys notifications and raises a user_unstaged event prior to the user becoming unstaged and the user object being saved.

User#unstage! no longer updates user attributes and saves the object before triggering the `user_unstaged` event.

* Update one more spec

* Assign attributes after unstaging
2020-03-17 16:48:24 +01:00
Blake Erickson 269ec70ba8 DEV: Only show deprecation message for non-whitelisted requests
As another step toward fully dreprecating query parameter authentication
in API requests this change prevents an admin dashboard message from
showing up if using a whitelisted route like rss feeds or the
mail-receiver route.
2020-03-16 12:05:24 -06:00
Martin Brennan 793f39139a
FEATURE: Send notifications for time-based and At Desktop bookmark reminders (#9071)
* This PR implements the scheduling and notification system for bookmark reminders. Every 5 minutes a schedule runs to check any reminders that need to be sent before now, limited to **300** reminders at a time. Any leftover reminders will be sent in the next run. This is to avoid having to deal with fickle sidekiq and reminders in the far-flung future, which would necessitate having a background job anyway to clean up any missing `enqueue_at` reminders.

* If a reminder is sent its `reminder_at` time is cleared and the `reminder_last_sent_at` time is filled in. Notifications are only user-level notifications for now.

* All JavaScript and frontend code related to displaying the bookmark reminder notification is contained here. The reminder functionality is now re-enabled in the bookmark modal as well.

* This PR also implements the "Remind me next time I am at my desktop" bookmark reminder functionality. When the user is on a mobile device they are able to select this option. When they choose this option we set a key in Redis saying they have a pending at desktop reminder. The next time they change devices we check if the new device is desktop, and if it is we send reminders using a DistributedMutex. There is also a job to ensure consistency of these reminders in Redis (in case Redis drops the ball) and the at desktop reminders expire after 20 days.

* Also in this PR is a fix to delete all Bookmarks for a user via `UserDestroyer`
2020-03-12 10:16:00 +10:00
Sam Saffron 1f34f653bf
FIX: last ip address could point at wrong ip
Due to unicorn env object recycling request.ip could point at the wrong
ip address by the time defer block is called. This usually would happen
under load.

This also avoids keeping the entire request object as referenced by the
closure.
2020-03-11 17:42:56 +11:00
David Taylor 4c9ca24ccf
FEATURE: Hash API keys in the database (#8438)
API keys are now only visible when first created. After that, only the first four characters are stored in the database for identification, along with an sha256 hash of the full key. This makes key usage easier to audit, and ensures attackers would not have access to the live site in the event of a database leak.

This makes the merge lower risk, because we have some time to revert if needed. Once the change is confirmed to be working, we will add a second commit to drop the `key` column.
2019-12-12 11:45:00 +00:00
Joffrey JAFFEUX 0d3d2c43a0
DEV: s/\$redis/Discourse\.redis (#8431)
This commit also adds a rubocop rule to prevent global variables.
2019-12-03 10:05:53 +01:00
David Taylor a227083c1c
FEATURE: Limit the number of active sessions for a user (#8411)
If a user has more than 60 active sessions, the oldest sessions will be terminated automatically. This protects performance when logging in and when loading the list of recently used devices.
2019-11-27 12:39:31 +00:00
Blake Erickson 15f6f57cdc DEV: Add update message for an outdated mail-receiver
Previous versions of the mail-receiver used query based api credentials,
if we detect this we will show a message in the admin panel to update
the mail receiver.
2019-11-08 17:32:22 -07:00
Blake Erickson 2db2003187 DEV: Add deprecation warning of non-header based API auth
This change adds a message to the admin panel if it detects an api
requests that doesn't use the new header based authentication method.

The message is to warn people to switch to header based auth and links
to the api documention topic on meta for more info.
2019-11-07 17:06:13 -07:00
David Taylor 52c5cf33f8
FEATURE: Overhaul of admin API key system (#8284)
- Allow revoking keys without deleting them
- Auto-revoke keys after a period of no use (default 6 months)
- Allow multiple keys per user
- Allow attaching a description to each key, for easier auditing
- Log changes to keys in the staff action log
- Move all key management to one place, and improve the UI
2019-11-05 14:10:23 +00:00
Krzysztof Kotlarek 427d54b2b0 DEV: Upgrading Discourse to Zeitwerk (#8098)
Zeitwerk simplifies working with dependencies in dev and makes it easier reloading class chains. 

We no longer need to use Rails "require_dependency" anywhere and instead can just use standard 
Ruby patterns to require files.

This is a far reaching change and we expect some followups here.
2019-10-02 14:01:53 +10:00
Sam Saffron dc9110cc43 FEATURE: track date api key was last used
Start tracking the date an api key was last used. This has already been
the case for user_api_keys.

This information can provide us with the ability to automatically expire
unused api keys after N days.
2019-09-03 18:11:30 +10:00
David Taylor af86cf46dc FEATURE: Allow API requests to specify the `DISCOURSE_VISIBLE` header
This allows API consumers to automatically update the user's last_seen time. The default behaviour is unchanged.
2019-04-15 17:34:34 +01:00
Leo McArdle b084750953 FIX: don't redirect incorrectly after full screen login (#7170)
Fixes two issues:
1. Redirecting to an external origin's path after login did not work
2. User would be erroneously redirected to the external origin after logout

https://meta.discourse.org/t/109755
2019-03-19 12:39:13 +00:00
Blake Erickson 7ac394f51f FIX: prevent mixed api auth headers & query params
When using the api and you provide an http header based api key any other
auth based information (username, external_id, or user_id) passed in as
query params will not be used and vice versa.

Followup to f03b293e6a
2019-03-12 17:33:21 -06:00
Blake Erickson f03b293e6a
FEATURE: Header based auth for API requests (#7129)
Now you can also make authenticated API requests by passing the
`api_key` and `api_username` in the HTTP header instead of query params.

The new header values are: `Api-key` and `Api-Username`.

Here is an example in cURL:

``` text
curl -i -sS -X POST "http://127.0.0.1:3000/categories" \
  -H "Content-Type: multipart/form-data;" \
  -H "Api-Key: 7aa202bec1ff70563bc0a3d102feac0a7dd2af96b5b772a9feaf27485f9d31a2" \
  -H "Api-Username: system" \
  -F "name=7c1c0ed93583cba7124b745d1bd56b32" \
  -F "color=49d9e9" \
  -F "text_color=f0fcfd"
```

There is also support for `Api-User-Id` and `Api-User-External-Id`
instead of specifying the username along with the key.
2019-03-08 09:13:31 -07:00
Guo Xiang Tan d32900292d FIX: Don't update `User#last_seen_at` when PG is in readonly take 3. 2019-01-22 18:07:48 +08:00
Guo Xiang Tan 3c6a8a2bb1 Partially revert 4466fcf1bc. 2019-01-21 15:41:01 +08:00
Guo Xiang Tan 4466fcf1bc FIX: Don't update `User#last_seen_at` when PG is readonly take 2. 2019-01-21 13:49:08 +08:00
Guo Xiang Tan c732ae9ca9 FIX: Don't update `User#last_seen_at` when PG is in readonly. 2019-01-21 13:29:29 +08:00
Régis Hanol 182b34243d
FIX: opts is a hash in 'log_on_user'
cc @nbianca
2018-11-12 16:00:12 +01:00
Bianca Nenciu 5af9a69a3b FIX: Do not check for suspicious login when impersonating. (#6534)
* FIX: Do not check for suspicious login when impersonating.

* DEV: Add 'impersonate' parameter to log_on_user.
2018-11-12 15:34:12 +01:00
Régis Hanol d17c8df926 Only check for suspicious login for staff members 2018-10-26 00:29:28 +02:00
David Taylor 56e0f47bcd FIX: Do not update `last_seen` for API access
This regressed in 2dc3a50. I have now added tests for the behavior.
2018-10-25 13:38:57 +01:00