Using the API, can't PUT to topic unless slug is on the URL

Contribuir Característica
1

Found this out while writing a request to change the tags on a topic.

Basically, this doesn’t work:

PUT /t/123.json?api_username=...&api_key=...

{
  tags: ['a']
}

The server responds with:

403
{
  "errors": [
    "You are not permitted to view the requested resource."
  ],
  "error_type": "invalid_access"
}

However, if you put the topic slug on the URL, everything works fine (i.e. PUT /t/why-arent-there-better-animals/123.json?api_username=...&api_key=...)

This is inconsistent with the other topic API methods which do not require a slug, and differs from the behavior described in the API documentation: Discourse REST API Documentation

1 me gusta
2

Does it work if you use a wrong slug?

2 Me gusta
3

I’m pretty sure the answer is No, based on previous testing, but I don’t have the time to reproduce this right now.

1 me gusta
4

Yes it appears that you need the slug to be present to make the PUT request on topics and you can use the wrong slug and it will work fine.

See my demo:

discourse_topics.gif1890×954 1.87 MB

4 Me gusta
5

Okay, so just hardcode a slug of a single dash :slight_smile:

4 Me gusta
6

That’s fine for a workaround but it’s still a bug.

1 me gusta
7

How is that a bug and not required syntax?

To work as expected routing depends on URLs to be in a certain format.

So this seems more like “change the way the API works with improper URLs” feature request than a bug to me.

3 Me gusta
8

Well, none of the other topic API methods require that, so I’d call it a bug.

2 Me gusta
9

Put differently, why is it reasonable for GET /t/:topicId to work and DELETE /t/:topicId to work and PUT /t/:topicId to not work?

4 Me gusta
10

I edited the original topic to clarify why this is a bug, but I’d like to highlight that the API documentation itself states that this should work:

I think my previous point is relevant as well.

2 Me gusta
11

Esto no cumple con nuestra definición de Contribute > Bug, pero no tengo ningún problema con un PR que lo limpie, ya que simplificaría la API.

2 Me gusta