Project

General

Profile

Actions

User story #2144

closed

Bootstrap REST API to manage deployment, PT lib reloading, etc

Added by François ARMAND over 12 years ago. Updated almost 12 years ago.

Status:
Released
Priority:
3
Category:
Web - Maintenance
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

We need to define a REST API that will allow to manage common service in Rudder (in short, more or less all the one with a batches, plus some other) :

  • regenerate dyn groups
  • reload PT library
  • generate promises (deploy)
  • etc

That issue is only to bootstrap the REST API (only /api/status and /api/deploy/reload implemented), other issues track:

  • authentication #2204
  • individual services:
    • dynamic groups reloading: #2205
    • technique library reloading: #2206
    • archive related things: #2228
Actions #2

Updated by Jonathan CLARKE about 12 years ago

  • Target version changed from 2.4.0~alpha3 to 2.4.0~alpha4
Actions #3

Updated by François ARMAND about 12 years ago

For now, we have decide to have a fully NON-AUTHENTICATED REST API, and let Apache manage that part.

It will be really great to have at least a configuration option to force user to be authenticated to use the API.

Actions #4

Updated by François ARMAND about 12 years ago

  • Status changed from New to In progress
Actions #5

Updated by François ARMAND about 12 years ago

  • Assignee set to François ARMAND
Actions #6

Updated by François ARMAND about 12 years ago

  • Subject changed from REST API to manage deployment, PT lib reloading, etc to Bootstrap REST API to manage deployment, PT lib reloading, etc
  • Description updated (diff)
Actions #7

Updated by François ARMAND about 12 years ago

To sum up:

  • the API is available without authentication if configuration property "rudder.rest.allowNonAuthenticatedUser" is true
  • the username used as the actor of rest action is:
    • the authenticated user if one is available
    • else the string given in header X-REST-USERNAME
    • else "UnknownRestUser" if none of the above is available.

A simple status REST URL is available at: "/api/status" which send a plaintext answer containing "OK"
Deployment can be trigger with "/api/deploy/start", which sent a plaintext answer containing "OK"

Actions #8

Updated by François ARMAND about 12 years ago

  • Status changed from In progress to Pending technical review
  • % Done changed from 0 to 100
Actions #9

Updated by François ARMAND about 12 years ago

  • Description updated (diff)
Actions #10

Updated by François ARMAND about 12 years ago

  • Description updated (diff)
Actions #11

Updated by François ARMAND about 12 years ago

  • Description updated (diff)
Actions #12

Updated by Nicolas CHARLES about 12 years ago

  • Status changed from Pending technical review to 10

I guess this is correct, but I'm a bit puzzled by the fact that if the user is not authnd, then a header in the request is read... isn't there any risk of spoofing header request, or am I missing something ?

Actions #13

Updated by François ARMAND about 12 years ago

There is only two case:

  • either authentication is requested for using the REST API, and in such case the authentication means is decorelated from Rudder (more precisely, its managed by Spring Security and can be anything supported by that framework)
  • or no authentication is required, and in such case we assume confidence in the client, and just want to be able to log as much information as we can. Part of that information is who/what the client is, what we can't decide based on an authentication token, and so, as we are in a trusted relationship with the client, we ask "please, add in that header relevant information about yourself".

Hope it make things clearer,

Actions #14

Updated by Jonathan CLARKE almost 12 years ago

  • Status changed from 10 to Released
Actions

Also available in: Atom PDF