February 2023 - Pdb-tech

new rate limiting mechanism is too strict
by Theo de Raadt 13 May '24

13 May '24

At YYCIX, we run arouteserver, which polls peeringdb. On May 15 (I think) we started seeing failures to download peeringdb records, which has resulted in our routeserver configuration not being updated as usual. I've become aware that the API has a new rate filtering mechanism, for non-APIKEY accesses. Well, arouteserver doesn't do APIKEY, and I don't see how the author of arouteserver would have received any notice that this was suddenly mandatory, nor all the arouteserver users. I think peeringdb should have looked more carefully into the no-APIKEY accesses to determine what downstream effects might occur from this change. Testing further manually, I observe some really crazy behaviour. Using a regular browser, I can keep reloading the same record over and over without hitting any limit. Using a command-line client (curl or OpenBSD ftp(1)), i hit some extremely strict limits very quickly. On the 11th lookup, I receiving this, and it started counting down: {"message": "Request was throttled. Expected available in 59 minutes. Authenticate for less restrictions. For more information: https://docs.peeringdb.com/howto/api_keys/", "meta": {"error": "Too Many Requests"}} All requests are blocked for an hour. I paused, and tried a new lookup every 5 minutes. Half an hour later it allowed me to retrieve 1 record, but then continued the countdown: {"message": "Request was throttled. Expected available in 17 minutes. Authenticate for less restrictions. For more information: https://docs.peeringdb.com/howto/api_keys/", "meta": {"error": "Too Many Requests"}} If the new limit is 10 records an hour, I mean you could really just shut down the service entirely, there's really no difference. I understand using APIKEY is the new way, but the old way has effectively been disabled without notice. But also, why does this work in the browser? I can reload hundreds of times. Is the official browser User-agent being considered exempt from the rule? If so I don't understand what the protection plan is.. maybe we should all change our commandline tools to declare they are Chrome?

5 6

Re: [PDB Tech] OAuth client application help requested - cannot authorize with client secret
by Justin Cole 22 Feb '23

22 Feb '23

Thank you for the response Leo. I was able to get it working by excluding the authorization header and call like so: POST to https://auth.peeringdb.com/oauth2/token/<https://auth.peeringdb.com/oauth2/token/> Header: 'Content-Type': 'application/x-www-form-urlencoded' Body: 'grant_type=authorization_code&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&code=CODE&redirect_uri=CALLBACK_URI' It seems the system does not like the Basic auth header, nor does it like JSON as the request body. Hopefully this helps someone in the future. Thanks, Justin From: Leo Vegoda <leo(a)peeringdb.com> Sent: Wednesday, February 22, 2023 11:01 AM To: Justin Cole <justinc(a)redapt.com> Subject: Re: [PDB Tech] OAuth client application help requested - cannot authorize with client secret Hi Justin, 2.44.0 was just deployed to production. It included a fix for OAuth logins that failed when MFA was enabled. It's possible that this has resolved your issue. If not, please let us know. Release Notes<https://docs.peeringdb.com/release_notes/> docs.peeringdb.com<https://docs.peeringdb.com/release_notes/> [favicon.ico]<https://docs.peeringdb.com/release_notes/> Kind regards, Leo Vegoda PeeringDB Product Manager On Feb 15, 2023, at 19:52, Justin Cole <justinc(a)redapt.com<mailto:justinc@redapt.com>> wrote: Hello, I'm hoping someone can help me with my OAuth application problem. I have created an OAuth application with authorization-code grant type and entered my redirect uri. I can successfully call the /authorize/ endpoint, log in and receive an authorization code. However, the subsequent callback to /token/ always returns 401 Unauthorized with response body: { "meta": { "error": "Invalid username or password" } } Call to /token/ looks like: POST to https://auth.peeringdb.com/oauth2/token/<https://auth.peeringdb.com/oauth2/token/> Header: Authorization: Basic (Base64Encode(CLIENT_ID:CLIENT_SECRET)) Body: { grant_type:'authorization_code', code:'CODE', redirect_uri:'https://localhost:3001/api/auth/callback/peeringdb<https://localhost:3001/api/auth/callback/peeringdb>', client_id:'CLIENT_ID', client_secret:'CLIENT_SECRET' } I've determined that problem is the Authorization header value, however I've verified the values match the client id/client secret generated from PeeringDB (https://www.peeringdb.com/oauth2/applications/register/<https://www.peeringdb.com/oauth2/applications/register/>) are correct. What am I doing wrong? Or is there something I am missing to enable the OAuth application registration from working properly? Thank you, Justin _______________________________________________ Pdb-tech mailing list Pdb-tech(a)lists.peeringdb.com<mailto:Pdb-tech@lists.peeringdb.com> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech<https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech>

1 0

OAuth client application help requested - cannot authorize with client secret
by Justin Cole 16 Feb '23

16 Feb '23

Hello, I'm hoping someone can help me with my OAuth application problem. I have created an OAuth application with authorization-code grant type and entered my redirect uri. I can successfully call the /authorize/ endpoint, log in and receive an authorization code. However, the subsequent callback to /token/ always returns 401 Unauthorized with response body: { "meta": { "error": "Invalid username or password" } } Call to /token/ looks like: POST to https://auth.peeringdb.com/oauth2/token/ Header: Authorization: Basic (Base64Encode(CLIENT_ID:CLIENT_SECRET)) Body: { grant_type:'authorization_code', code:'CODE', redirect_uri:'https://localhost:3001/api/auth/callback/peeringdb', client_id:'CLIENT_ID', client_secret:'CLIENT_SECRET' } I've determined that problem is the Authorization header value, however I've verified the values match the client id/client secret generated from PeeringDB (https://www.peeringdb.com/oauth2/applications/register/) are correct. What am I doing wrong? Or is there something I am missing to enable the OAuth application registration from working properly? Thank you, Justin

1 0