I have a API deprecation notice but have no clue what’s causing it. We have the WordPress / Discourse plugin installed (and up-to-date) but according to the dev this should not cause the notice. How do i find out whats causing this notice?
Do you have any api keys listed under the admin / api section? Are they different than what the Wordpress plugin is using?
Yes, one for “all users” as is suggested (with publishing name set to “system”) and one for an admin account. I’ve tested both in WordPress, and turned them on/off in Discourse but tthe notice remains.
Thank you for looking into the number of API keys you have.
There is a 24 hour delay for the notification to go away. So once Discourse detects a deprecated api request it restarts the 24 hour clock.
Now that we know you have two api keys and it sounds like the only one you are aware of is for WordPress you can probably just create a new api key just for WordPress and delete the two original ones. This way we know for sure you only have one key being used and what is using it.
The issue with the WP Discourse plugin’s authentication methods was dealt with a couple of months ago, so as long as you’re on a recent version of the plugin, it shouldn’t be causing the notification that you are seeing. Do you have the WP Discourse Shortcodes plugin installed on your site? If so, I updated it last week to use header based authentication for its API calls. I don’t think that plugin is installed on many sites though.
Now that this API deprecation warning:
has had several months to simmer, I wanted to let everyone know that we will be fully deprecating API credentials in query parameters on April 6th, 2020. It will be available to self-hosters shortly thereafter when the next beta release is out.
During November 2019 we released an update to your admin dashboard that would appear if it detected this deprecated API authentication method. Please check your admin dashboard for this message and make the appropriate changes to any API integrations you may have. If you do not see this message you either have an API integration that triggers less than once every 24 hours or you don’t have any affected API integrations and have nothing to update.
We are making this change in an effort to further increase the security of all Discourse sites by removing the support of API authentication credentials inside of query parameters and requiring that authentication credentials are passed inside of HTTP Headers.
The only API endpoints that will not be affected and will continue to have support for credentials in query parameters will be requests to RSS feeds and the Mail Receiver endpoint.
Running through this change - it doesn’t look like the
Api-Username headers have been added to the
Access-Control-Allow-Headers setting - discourse/008-rack-cors.rb at master · discourse/discourse · GitHub
Once this deprecation comes in, the API will no longer be accessible programmatically - at least in the way we’re currently using it.
Am I missing something obvious here?
Duplicate here: API CORS Headers Incorrect
Although this was closed by @david I disagree with his explanation. There are scenarios where we want to generate an API key on behalf of a user, without them having to get approval from the user. In our use case, the API key generation should very much remain ‘hidden’ from the user, and hence our only choice is to use the Admin API keys, rather than User API keys.
I understand it’s not as simple as enable CORS by default for the Admin API headers, but this should at least be configurable in the same way that CORS origins are…
The admin API keys you’re providing to the browser clients bypass some significant ratelimiting. (Not all.) Making these available to an end-user browser is almost universally a mistake.
I appreciate this isn’t ideal - but what’s the alternative in our situation where we need to programmatically generate user specific API keys?
These keys also don’t provide ‘admin access’ from what we’ve experienced.
I can think of two possible ways forward from our perspective:
- Addition of programmatic generation of User API Keys
- Addition of scoping to Admin generated API Keys
Right now, rate limiting isn’t something we’re too worried about as we mostly handle that at the server layer, not the application layer. And as you can imagine, since we’re programmatically generating API keys, we’re quite happy to programmatically revoke them as well. In general we cycle the API key on each session or end of day.
I’d love to move forwards with a solution that didn’t feel like a compromise or a hack though!
Got this in my admin dashboard:
* We detected an API request using a deprecated authentication method. Please update it to use [header based auth](https://meta.discourse.org/t/-/22706). After updating this message may take 24 hours to disappear.
Also not sure if its somehow related to this, but sometimes i get a “connection not secure” Chrome warning when going through my forum. It happens randomly, not in all occasions. I see that the http://schema.org urls are the ones not going through https, but not sure how to fix all of this.
Forum URL: https://wmforum.geek.hr/
For the deprecated API request message, can you check your API keys in your admin dashboard
/admin/api/keys and see when they were last used? Do you know what integrations might be using one of your API keys?
The favicon loaded in this onebox is not loaded over https.
@blake Yeah i had some old API from year 2013. active, so i deactivated it. Was probably used to communicate with the WP Discourse plugin.
Ok added ico to authorized extensions and it looks like the problems are all gone now.
I’ve been getting warnings as well. The reason is webcal access from a calendar app. Will this still work after the April deadline?
I believe @Falco is adding support for webcal links?
Update the wp-discourse plugin and follow the directions to set it back up again with a new api key
Just to add – using a tool like Postman is fantastic and makes understanding and experimenting with the API very easy. However, I find Postman’s interface to be a little over-engineered and confusing for making simple calls. I prefer Insomnia (free, open source)-- much more simple and clear.
Hi guys, just started with Discourse 2 weeks ago and it’s a ride alright .
I have an issue when i request /session/current.json … The curent_user_serializer fails with error
`NoMethodError (undefined method `can_send_private_messages_to_email?' for nil:NilClass) /Users/stefanb/ab4/i-fikr-discourse/app/serializers/current_user_serializer.rb:118:in `can_send_private_email_messages' Rendering /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/diagnostics.html.erb within rescues/layout Rendered /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/_actions.html.erb (Duration: 1.0ms | Allocations: 729) Rendered /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/_source.html.erb (Duration: 5.1ms | Allocations: 6306) Rendered /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/_trace.html.erb (Duration: 5.5ms | Allocations: 3873) Rendered /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/_source.html.erb (Duration: 3.9ms | Allocations: 5372) Rendered /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/_trace.html.erb (Duration: 2.7ms | Allocations: 2816) Rendering /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/_request_and_response.html.erb Rendered /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/_request_and_response.html.erb (Duration: 2.8ms | Allocations: 3858) Rendered /Users/stefanb/.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/actionpack-6.0.1/lib/action_dispatch/middleware/templates/rescues/diagnostics.html.erb within rescues/layout (Duration: 315.7ms | Allocations: 232803) #<User id: 1, username: "sbrighiu", created_at: "2020-04-02 14:07:16", updated_at: "2020-04-09 11:59:13", name: nil, seen_notification_id: 4, last_posted_at: "2020-04-09 11:59:13", password_hash: [FILTERED], salt: "< &- & >", active: true, username_lower: "sbrighiu", last_seen_at: "2020-04-10 20:03:31", admin: true, last_emailed_at: nil, trust_level: 1, approved: true, approved_by_id: -1, approved_at: "2020-04-02 14:07:20", previous_visit_at: "2020-04-10 15:01:51", suspended_at: nil, suspended_till: nil, date_of_birth: nil, views: 0, flag_level: 0, ip_address: #<IPAddr: IPv4:127.0.0.1/255.255.255.255>, moderator: false, title: nil, uploaded_avatar_id: nil, locale: nil, primary_group_id: nil, registration_ip_address: nil, staged: false, first_seen_at: "2020-04-02 14:37:52", silenced_till: nil, group_locked_trust_level: nil, manual_locked_trust_level: nil, secure_identifier: nil>
Any ideas why this happens? Not a ruby guy … also maybe why it happened?
Is there a changelog for the ruby API?
I see 0.39.1 is latest, but there are only releases up to 0.38.0.
We’re on 0.31.0 right now and started seeing 404’s on April 7th with the
groups_add API, so I’m guessing this has to do with this deprecation.
Will updating to 0.39.1 be sufficient to remedy?
Also shortly after this we started seeing pg bouncer errors in the logs…
Appreciate any thoughts!
The changelog can be found here: discourse_api/CHANGELOG.md at master · discourse/discourse_api · GitHub
0.39.1 is on rubygems: discourse_api | RubyGems.org | your community gem host
Yes, it should be
This won’t be related to the API usage. It looks like a small network issue, but it has resolved itself (“Master server is active. Reconnecting…”)