Mark notifications as read from Discourse API

[duranmla (Alexis Duran)]

Hi all,

I am working in a project that has discourse integrated with several apps, by now, I need to be able to allow one of those external apps to mark notifications from discourse as read but of course, consuming the API.

For instance, if I try to hit the notifications/mark-read endpoint I will get

Nevertheless, I will stress that I have already manage basic things as CORS config and token handling from outside (For instance my component is able to login/logout the user and pull user notifications).

The idea is that this custom component has a button to “Mark all as read”

I have also seen this “clear_notifications” method
https://github.com/discourse/discourse/blob/90ce44867595073d91ace4aacbb948f1e4f1ecb0/app/controllers/application_controller.rb#L292-L316

And it while it looks like the thing I can use it seems to not be exposed or available for the usage outside discourse app?

Thanks in advance for any help.

Cheers!!

[Falco]

You should mark notifications as read from the backend, not from the frontend.

[duranmla (Alexis Duran)]

Thanks for the answer, nevertheless, just to double check: It means there is no built-in endpoint that I can use from outside front-end in order to mark the notifications as read?

I should add that functionality myself on the backend and then consume that new endpoint to mark notifications as read. It is like that?

[sam (Sam Saffron)]

Anything you can do from the website you can do from the API per:

Reverse engineer the Discourse API

Discourse is backed by a complete JSON api. Anything you can do on the site you can also do using the JSON api. Many of the endpoints are properly documented in the discourse_api gem, however some endpoints lack documentation. To determine how to do something with the JSON API here are some steps you can follow. Example: recategorize a topic. Go to a topic and start editing a category: [image] Open Chrome dev tools, switch to the Network tab, select XHR filter: [image] Perform the op…

The problem here is that delegating this to clients is inherently unsafe. How do you have confidence the end users are even logged in to Discourse?

[duranmla (Alexis Duran)]

In my very specific case the problem was related to the fact that I had one plugin in place that rewrite the class Discourse::Cors method def self.apply_headers(cors_origins, env, headers), thus, I didn’t have the behaviour of the Discourse source code defined at https://github.com/discourse/discourse/blob/master/config/initializers/008-rack-cors.rb#L44 but instead some custom thing that I don’t even need.

Once I remove the plugin I get back the core definition for CORS and everything works as expected.