Sì, ora WebHDFS accesso è protetto con OAuth2. Questo fa parte del meccanismo generale per pretendere le API REST in FIWARE, che esegue l'autenticazione e l'autorizzazione. Puoi trovare maggiori dettagli here.
Prima di tutto, è necessario richiedere un token OAuth2 al generatore di token Cosmos. Questo è un servizio in esecuzione in cosmos.lab.fiware.org:13000
. È possibile farlo utilizzando qualsiasi client REST, il modo più semplice sta usando il comando ricciolo:
$ curl -k -X POST "https://cosmos.lab.fiware.org:13000/cosmos-auth/v1/token" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=password&[email protected]&password=xxxxxxxx"
{"access_token": "qjHPUcnW6leYAqr3Xw34DWLQlja0Ix", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "V2Wlk7aFCnElKlW9BOmRzGhBtqgR2z"}
Come si può vedere, le credenziali Lab FIWARE sono tenuti nel payload, sotto forma di un tipo di sovvenzione basata su password .
Una volta ottenuto il token di accesso (nell'esempio precedente, è qjHPUcnW6leYAqr3Xw34DWLQlja0Ix
), è sufficiente aggiungerlo alla stessa richiesta WebHDFS che si stava eseguendo in passato. Il token viene aggiunto utilizzando l'X-Auth-Token
intestazione:
$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/to/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix"
{"FileStatuses":{"FileStatus":[...]}}
Se si tenta la richiesta di cui sopra con un token a caso il server restituirà il token non è valido; questo è perché avete non autenticati correttamente:
$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/frb/path/tp/the/data?op=liststatus&user.name=frb" -H "X-Auth-Token: randomtoken93487345"
User token not authorized
Allo stesso modo, se si utilizza un gettone valido, ma si cerca di accedere a un altro userspace HDFS, si otterrà la stessa risposta; questo è perché siete non autorizzato di accedere a qualsiasi spazio utente HDFS ma quello di tua proprietà:
$ curl -X GET "http://cosmos.lab.fiware.org:14000/webhdfs/v1/user/fgalan/path/tp/the/data?op=liststatus&user.name=fgalan" -H "X-Auth-Token: qjHPUcnW6leYAqr3Xw34DWLQlja0Ix"
User token not authorized
IMPORTANTE AGGIORNAMENTO:
Dall'estate 2016, cosmos.lab.fiware.org
non è workin più. Invece, sono stati impostati un paio di cluster, storage.cosmos.lab.fiware.org
e computing.cosmos.lab.fiware.org
. Per quanto riguarda il server di autenticazione di Cosmos, attualmente viene eseguito in computing.cosmos.lab.fiware.org
, porta TCP/13000.
Perché usando' X-Auth-token' (un'intestazione OpenStack) invece di utilizzare l'intestazione utilizzata nello standard OAuth2: 'Autorizzazione'? –
Stiamo utilizzando FIWARE PEP Proxy nel mezzo (https://github.com/ging/fi-ware-pep-proxy). Quel componente specifica l'uso di 'X-Auth-Token' in questo pezzo di documentazione: https://github.com/ging/fi-ware-pep-proxy#how-to-use. – frb
Ora, queste soluzioni non funzionano :( – miguelbemartin