Triggering a backup via admin API causes the api_key to become only valid for system user

Contribute Bug

AI-generated summary

Triggering a backup via admin API causes the api_key to become only valid for system user

supermathie found an issue where triggering a backup via admin API changes the API key’s user ID from nil to -1, making it only valid for the system user. This is demonstrated through a step-by-step reproduction with API calls and database queries.

sam suggested checking the underlying table before and after the operation, which supermathie did, showing the change in the API key’s user ID.

supermathie considered this issue not urgent, but concerning due to the unintended side effect of modifying the API key. sam suspected the restore process might be involved, but zogstrip disagreed.

Despite gerhard being unable to reproduce the issue, the bug still exists.

1

Before:

image
image1135×152 8.95 KB

Reproduction:

$ api_key=340496f95ab2f28cc45f575cbfcc28edd10db076beb1139da14b3fa80bb23dd2
$ curl -XPOST -H 'Content-Type: application/json' "http://discoursedev:3000/admin/backups.json?api_key=$api_key&api_username=michael" -d '{ "with_uploads": true }'
{"success":"OK"}
$ curl "http://discoursedev:3000/admin/backups.json?api_key=$api_key&api_username=michael"
(HTML error page as I'm in development mode)
$ curl "http://discoursedev:3000/admin/backups.json?api_key=$api_key&api_username=system"
[{"filename":"discourse-2018-01-12-112341-v20180111092141.sql.gz","size":3216556,"link":"//discourse/admin/backups/discourse-2018-01-12-112341-v20180111092141.sql.gz"}]

After:

image
image986×144 8.83 KB

6 Likes
2

Can you look at the underlying table, before and after?

bin/rails c
> ApiKey.all
2 Likes
3

Before

[4] pry(main)> ApiKey.all
  ApiKey Load (0.4ms)  SELECT "api_keys".* FROM "api_keys"
=> [#<ApiKey:0x0000000d615e38
  id: 3,
  key: "scoobydoowhereareyou",
  user_id: nil,
  created_by_id: -1,
  created_at: Mon, 15 Jan 2018 16:20:10 UTC +00:00,
  updated_at: Mon, 15 Jan 2018 16:20:10 UTC +00:00,
  allowed_ips: nil,
  hidden: false>]

Operation

○ → curl -XPOST -H 'Content-Type: application/json' \
  "http://discoursedev:3000/admin/backups.json?api_key=scoobydoowhereareyou&api_username=michael" \
  -d '{ "with_uploads": true }'
{"success":"OK"}

After

[5] pry(main)> ApiKey.all
  ApiKey Load (0.3ms)  SELECT "api_keys".* FROM "api_keys"
=> [#<ApiKey:0x000000064318d0
  id: 3,
  key: "scoobydoowhereareyou",
  user_id: -1,
  created_by_id: -1,
  created_at: Mon, 15 Jan 2018 16:20:10 UTC +00:00,
  updated_at: Mon, 15 Jan 2018 16:20:31 UTC +00:00,
  allowed_ips: nil,
  hidden: false>]
6 Likes
4

How urgent is this to fix @supermathie? I’m unclear who this bug affects?

5

It’s likely not urgent to fix (I only came across it by accident), but it concern me that the codepath has an unintended side effect of modifying the API key used to access it.

6

Maybe @zogstrip can have a quick look here, my guess is that something about the restore process may be fussing with api keys post restore.

7

I don’t think it’s related to the restore process since @supermathie is just doing a backup :flushed_face:

But yeah, I’ll have a look.

1 Like
9

I gave it a quick try since I was working on backups. I can’t reproduce it. I’m closing it for now.

5 Likes