2010-06-22 11 views
31

Vorrei configurare un account Amazon S3, creare un bucket, caricare alcuni dati e questi dati saranno disponibili tramite HTTP GET con autenticazione di base.Amazon S3 supporta la richiesta HTTP con autenticazione di base

So che esistono diversi modi per autenticare i dati S3 (stringa di query e così via), ma vorrei essere in grado di fornire un semplice schema nome utente/password per l'autenticazione.

È possibile?

+1

puoi usare [s3auth.com] (http://www.s3auth.com), che è una soluzione hosted gratuita per quello che ti serve – yegor256

+0

[s3auth ] (http://www.s3auth.com/) è sicuramente la soluzione per questo. –

risposta

10

No, questo non è possibile. È necessario conformarsi a Amazons Authentication API

Controllare alcuni dei wrapper elencati here.

+1

Non penso che l'articolo stia affermando che puoi usare l'autenticazione di base con S3. –

+1

Vedi anche http://aws.amazon.com/s3/faqs/#How_can_I_control_access_to_my_data_stored_on_Amazon_S3 –

0

Sono di AdroitLogic. Circa l'articolo collegato, mostra come l'UltraESB potrebbe essere posizionato tra il tuo client e Amazon S3 per autenticare le tue richieste. Se necessario, potrebbe creare un servizio "proxy" che accetterà l'autenticazione di base dal client e invierà le credenziali come previsto da Amazon S3. Questo potrebbe essere fatto in modo triviale e nasconderà qualsiasi complessità per il tuo cliente.

20

È possibile svilupparlo autonomamente come un'app Web o una parte dell'applicazione esistente. Consumerà richieste HTTP, recupererà il loro componente URI, lo convertirà in nome oggetto S3 e utilizzerà getObject() per ottenere il suo contenuto (utilizzando uno degli S3 SDK disponibili, ad esempio AWS Java SDK).

In caso contrario, è possibile provare una soluzione ospitata - s3auth.com (Sono uno sviluppatore). È un progetto open source e puoi vedere come questo meccanismo è implementato internamente allo one of its core classes. richiesta HTTP viene elaborato dal servizio e poi ri-tradotto a schema di autenticazione interna Amazon S3:

diagramma

http://s3auth:[email protected]/texry/packages.png

Questa architettura spiega come il progetto è realizzato. L'immagine PNG viene caricata dal bucket Amazon S3 maven.s3auth.com, che non è leggibile in modo anonimo. URL completa di questa immagine è

http://s3auth:[email protected]/texry/packages.png 

controllare anche questo articolo: Basic HTTP Auth for S3 Buckets

+0

Questo è esattamente quello che stavo cercando! Le istruzioni sono state recentemente chiarite e la configurazione è molto semplice. –

+0

Per chiarire l'ultimo bit della tua risposta, l'URL standard per una risorsa sarebbe 'http: // maven.s3auth.com/texry/packages.png', ma una volta autenticato diventa' http: // s3auth: s3auth @ maven.s3auth.com/texry/packages.png', corretto? –

+0

Che cos'è "l'URL standard"? :) L'URL in cui è possibile scaricare il documento è 'http: // s3auth: s3auth @ maven.s3auth.com/texry/packages.png' e include le informazioni di autenticazione – yegor256

11

Con sovrapposizione di più servizi AWS si può ottenere qualcosa di simile ad autorizzazione HTTP di base.

  1. Creare un sito statico s3.
  2. Creare una distribuzione CloudFront per servire il sito statico s3 (utilizzare l'URL del sito statico e non il nome del bucket)
  3. Utilizzare AWS WAF per creare una regola che consente solo le richieste con l'intestazione HTTP corretta. Questa sarà una regola della partita di puntura sui contenuti dell'intestazione Autorizzazione.
  4. Usa Route53 per instradare un dominio personalizzato per il CloudFront Distribuzione

Ora si dovrebbe avere un sito statico, che si può accedere solo con il nome utente e la password corretti.

NOTA: usando questa impostazione non verrà richiesto per voi credenziali come la richiesta viene bloccato con un 403 Forbidden invece di 401 non autorizzato.

NOTA: È possibile creare direttamente una distribuzione di CloudFront davanti a un bucket s3, ma non sarà possibile impostare automaticamente un file di indice radice in sottocartelle.

+1

per l'aggiunta di intestazione alle richieste? Plugin Chrome o alcuni di questi? –

13

Questo è ora possibile utilizzando CloudFront e Lambda @ Edge (generalmente disponibile da luglio 2017 nella regione us-east-1).

  1. Creare un secchio S3
  2. Setup una distribuzione CloudFront in davanti al secchio, limitando l'accesso al secchio in modo che solo CloudFront può accedere direttamente
  3. Creare una funzione lambda, che imitare base HTTP Autentica handshake con il browser. Assegnalo al comportamento di CloudFront.

Ecco la funzione lambda: https://gist.github.com/lmakarov/e5984ec16a76548ff2b278c06027f1a4

Ecco un articolo con maggiori dettagli: https://medium.com/@lmakarov/serverless-password-protecting-a-static-website-in-an-aws-s3-bucket-bfaaa01b8666

3

La risposta breve è no, non si utilizza autenticazione base. Ma ecco un modo che è effettivamente uguale all'autent semplice, e questo è facilmente rispetto ad altre soluzioni elencate. Credo che sia sicuro, ma non lo so per certo.

È possibile impostare le condizioni su serbatoi s3 che corrispondono alle intestazioni della richiesta. Ad esempio, è possibile utilizzare le intestazioni useragent e referer come equivalenti a nome utente e password nell'autenticazione di base. Normalmente useragent è il browser e OS (come Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0) e il referer è la pagina Web precedente

Ecco un esempio di criterio bucket s3 che consente di inserire oggetti e ottenere oggetti facendo corrispondere l'useragent e il referer (nota cambia : BUCKETNAME, USERNAME, PASSWORD, AWS_REGION, e FILENAME per i dati):

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
     { 
      "Sid": "allow-username-and-password-access", 
      "Effect": "Allow", 
      "Principal": { 
       "AWS": "*" 
      }, 
      "Action": [ 
       "s3:PutObject", 
       "s3:GetObject" 
      ], 
      "Resource": "arn:aws:s3:::BUCKETNAME/*", 
      "Condition": { 
       "StringEquals": { 
        "aws:UserAgent": "USERNAME", 
        "aws:Referer": "PASSWORD" 
       } 
      } 
     } 
    ] 
} 

per mettere una risorsa nel secchio è possibile utilizzare una richiesta ricciolo come questo (cambio nota: BUCKETNAME, USERNAME, PASSWORD, AWS_REGION, e FILENAME):

curl --user-agent USERNAME --referer PASSWORD --upload-file "FILENAME" --request PUT "https://s3-AWS_REGION.amazonaws.com/BUCKETNAME/FILENAME" 

Per ottenere utilizzare la risorsa si può usare qualcosa di simile:

curl --user-agent USERNAME --referer PASSWORD "https://s3-AWS_REGION.amazonaws.com/BUCKETNAME/FILENAME" > FILENAME 

Ancora una volta, credo che questo è sicuro, come l'useragent, e referer devono essere crittografati se siete usando https, ma per favore dimmi se non lo è.

+0

Eccellente. Questo è esattamente quello che stavo cercando !. Sono d'accordo che è sicuro. – sudheerchamarthi

0

Io stesso stavo cercando di trovare una soluzione a questo problema. This post qui li ha elencati tutti. Citando le linee:

Sono mesi che cerco una soluzione per aggiungere l'autenticazione HTTP di base ai bucket S3 su Amazon.Ci sono opzioni che coinvolgono URL pre-firmati (solo oggetti singoli), utilizzando un servizio gratuito o commerciale di terze parti (problemi di privacy), girando su un EC2/Heroku/ecc. con le richieste da middleware a proxy (complicate e non serverless), usando page redirects and bucket policies (non sicuro).

benna soluzione politica: ho provato personalmente questo e sembra perfettamente sicuro a me (a meno che non si dispone di un modo per bypassare le politiche benna AWS). Richiede solo un secchio s3 per funzionare. Semplice da implementare. Idea di base:

  1. Limita l'accesso all'intero sito, tranne consentire l'accesso pubblico al file di ingresso e al file segreto.
  2. voce del file secure.html che accetta un input all'utente la password e reindirizza al file segreto
  3. Segreto File thisisasecret che reindirizza al file principale (index.html) che ospita il vero contenuto del sito
  4. Main File main.html che consente solo l'accesso alle richieste originate dallo stesso sito.
  5. Tutti gli altri contenuti come i file css, js sarebbero limitati da un criterio bucket che consentirà loro di essere pubblicati se la richiesta è originata dall'URL del bucket.

Uso AWS Lambda @ Bordo: Questa soluzione richiede s3, AWS lambda e aws CloudFront per operare. Idea di base:

  1. Creare un secure.html. Crea caselle di testo per inserire le credenziali di base dall'utente qui. Questo file dovrebbe essere accessibile pubblicamente e dovrebbe chiamare una funzione lambda.
  2. Durante la configurazione di cloudfront creare un comportamento che dice "se si desidera raggiungere index.html, è necessario farlo tramite l'URL firmato".
  3. Proprio come sopra, creare un criterio bucket per consentire l'accesso ai file js, css, ecc. Solo quando l'origine è l'URL del bucket.
+0

Collegamento alla soluzione Lambda: http://johnpreston.ews-network.net/posts/s3-and-cloudfront-basic-auth-hack – rahuljain1311

0

Dai un'occhiata a my answer here in questa domanda un po 'correlata.

La domanda era quella di ottenere un ELENCO di oggetti bucket senza la necessità dell'autenticazione di accesso S3. Quindi, dalla tua domanda, la mia risposta in realtà non spiega la tua richiesta di Http-request with basic username/password authentication - ma piuttosto dà la possibilità di rendere privato il bucket e recuperare i suoi dati conoscendo uno identity-pool (ID) e uno Amazon Resource Name (ARN) (che puoi considerare simile a nome utente e password). Naturalmente, per ottenere (ID) e (ARN) è necessario eseguire alcune impostazioni, lavorare nelle pagine principali di AWS as described in my 17-step answer here... e, inoltre, non fa parte della richiesta GET, ma viene fornita all'interno del framework AWSS3 fornito da Amazon. . Spero, ti dia ancora più opzioni alla tua domanda;)