ddclient / ddclient

Ddclient updates dynamic DNS entries for accounts on a wide range of dynamic DNS services.

Home Page:https://ddclient.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Gandi has deprecated API keys

mpartel opened this issue · comments

Gandi now recommends Personal Access Tokens instead of API keys.

Currently, the authorization header looks like Authorization: Apikey <password>
With Personal Access Tokens, it should be Authorization: Bearer <password>

I tried making this change in ddclient, and it works, but of course just changing it would break things API key users.

I did not find a timeline for when Gandi will remove API keys.

It seems that this is effective now :-(
Can you propose a patch/MR ?

@G-eos here is an untested pull request. Can you check whether this works?

Yes it works well :) thanks !

API keys still work, therefore #625 broke all your existing Gandi users. I suggest to revert that PR and adopt #626 to allow both, Bearer and Apikeys.

Crap, I am sorry for the bad info. And this breaking existing user ! This did not work for me. May this was another issue. I raised question to Gandi support today to get an official info on when it is planned to stop it.
Note that the API Key is already announced as deprecated.

@G-eos API keys are deprecated for many years now, and yet they still work. At least they did 3 weeks ago, when I migrated away from them for other reasons. Note that API keys require Gandi's "Classic DNS" server. If you are on LiveDNS, you need a PAT for some reason. Luckily, supporting both is trivial.

(I don't really understand Gandi's policy here. What difference does it make if I add an opaque string prefixed with "Bearer" to adding an opaque string prefixed with "Apikey"? That's one and the same to me.)

@G-eos @mpartel are you available to test #636 ? Ideally with both an API key and a personal access token 😉

☑️ Tested with personal access tokens.

I don't have time to properly test with API keys, but the PR looks like it should work, and turning off use-personal-access-token while using a personal access token did result in a failure, as it should.

Some more possible approaches:

  • password: my-gandi-api-key for an API key and personal-access-token: my-gandi-personal-access-token for a personal access token. If both are given, ignore password (with a warning).
  • Try password as a PAT. If that fails, automatically retry as an API key. To avoid frequent authentication failures for API key users, we could cache a boolean that means "password foo is actually an API key" when PAT auth fails but API key auth succeeds. (If the password setting is changed, that cached entry would no longer apply so the new password would be tried as a PAT.)

I ask Gandi Support this week about an official the end date of API key. The current status is no defined date to end it, this will be announced in the changelog.

Once again sorry for the too quick move which break current behavior.

Answer from support in french:
"Je viens d'avoir un retour en interne.

Nous n'avons pour le moment pas date de fin de vie pour les API Keys.

Si cela venait à changer dans quelques mois je pense que nous mettrons l'information sur notre page d'aide https://api.gandi.net/docs/changelog/
"

☑️ Tested with personal access tokens.

I don't have time to properly test with API keys, but the PR looks like it should work, and turning off use-personal-access-token while using a personal access token did result in a failure, as it should.

Does some test are still needed ? Sorry not able to test API key, I do not have one (and cannot create new).

I'd vote for merging it now.