Architecture #4174
closed
Deprecate API v1
Description
We want to get rid of API v1, as it is not a good thing from a security point of view.
Before being able to deprecate it, we need to
- list all of there current use cases
- port functionality to API v2,
- find workaround or usage evolution for past use case not cover at identity.
That last point is important, especially if a feature relies one the non-authenticated aspect of API
To remember purpose, API v1 covers:
- api/status
- api/deploy/reload
- api/dyngroup/reload
- api/techniqueLibrary/reload
- api/archives/{list, archive, restore, zip}/...
A quick search raise the following usage in our code base:
- in Techniques
- initial-promises and system technique "distributePolicy", in aliveCheck.cf => "sites_to_check": /api/status
- system technique "distributePolicy", techniqueReload.st => root_technique_reload_rest_url: /api/techniqueLibrary/reload
- some tools look for Rudder status with "curl -s http://localhost/rudder/api/status"
So, before trying to decide what to do, do I miss other usage ?
Matthieu, assigned to you so that you see it, but it's just because I feel that the main usage of these API v1 may be in tooling around Rudder and Techniques... So as soon as you don't see any other usage, please pass the token to other (NicoP, NicoC, etc) so that they can react.
Updated by Vincent MEMBRÉ over 11 years ago
why not having a "default" api account that can only access to /api/status and /technique/reload, having a fixed token?
Updated by François ARMAND over 11 years ago
How did you imagine that ?
I see at least two problem to overtake with that solution: the first is because we don't have authorization by API.
The second is: because having a default token-name with a fixed token is like having no authentication at all - and so, well, it's simpler to just kept the current situation.
Updated by Vincent MEMBRÉ over 11 years ago
- Target version changed from 2.9.0~rc1 to 2.9.0~rc2
This won't be done for beta1
Updated by Vincent MEMBRÉ over 11 years ago
- Target version changed from 2.9.0~rc2 to 2.9.0
Delayed to 2.9 finale release
Updated by Nicolas CHARLES over 11 years ago
And we also have rewrite in the apache configuration
The technique reload is necessary after upgrade, and used by touching a file on the FS, and then promises checking this files existance, and curling the API
The site status is only for checking site availability, and restarting various part in case of failure
How could we replace these calls ?
Updated by François ARMAND over 11 years ago
I feels like the status URL could be kept. It has zero impact (no read nowhere, no update, nothing), just handling a URL, so nothing more than the login page. And if that one does not follow standard API naming (and can be called without authz token), that seems to be OK.
For technique reloading, it seems that we could have it in the standard API. But in that case, it means that local script need to have a token (not sur it is already the case).
Updated by Jonathan CLARKE 
Updated by Matthieu CERDA 
Updated by 
Updated by
Updated by François ARMAND over 8 years ago
Again missed the line. But 4.1 will have a focus on API !