2013-10-23 39 views
12

L'attività su cui sto lavorando ora è impostare l'autorizzazione di Google per accedere alle risorse della mia organizzazione.Google Cloud Console: URI di reindirizzamento non valido

Ma c'è un problema con questa attività. La mia organizzazione utilizza un dominio non standard per la propria rete locale: domain.off. E quando provo a impostare "http://dev.domain.off:12345/auth/google/callback.html" come callback oauth2 in Google Cloud Console (https://cloud.google.com/console), visualizzo l'errore "URI di reindirizzamento non valido".

Non riesco a utilizzare l'indirizzo diretto con il dominio Internet corretto perché ci sono molti altri servizi nel dominio di sviluppo privato della mia organizzazione. Devo usare quel conflitto con indirizzi diversi.

Non posso utilizzare l'ambiente di produzione con indirizzo diretto per gli scopi di sviluppo. L'ambiente di sviluppo ha solo indirizzi privati, domain.off.

Non riesco a modificare l'ambiente di sviluppo buche per modificare tutti gli indirizzi di dev privati ​​in pubblico. Questo è un compito non della mia portata.

C'è qualche soluzione al mio problema? L'unica soluzione che vedo ora è chiedere agli sviluppatori di Google di rimuovere o modificare il validatore URI nel modulo di impostazione di callback oauth per accettare domini non standard.

+0

Non so nulla di google cloud. Solo l'idea. Forse potresti utilizzare un URL valido e quindi utilizzare apache con le direttive proxy come proxypass e proxypassreverse per gestire la richiesta. –

+0

Questo è un aiuto 2 u: https://groups.google.com/forum/#!topic/google-plus-developers/6j6JNmewCXI –

risposta

1

dal momento che non è possibile utilizzare l'indirizzo diretto con dominio corretto internet

si potrebbe provare qualcosa di simile

È possibile creare un sottodominio master per ottenere tutte le risposte di Google auth e reindirizzare a correggere sottodominio utilizzando lo "stato" parametro di query.

Ad esempio, creare google.mydomain.com e utilizzarlo come "URI di reindirizzamento" valido e Apache reindirizzerà questo URL a ciascun utente con funzionalità di reindirizzamento (o riscrittura).

Maggiori informazioni su apache reindirizza in http://www.simonecarletti.com/blog/2009/01/apache-query-string-redirects/

Ecco il codice:

RewriteEngine On 
RewriteCond %{HTTP_HOST} ^google\. 
RewriteCond %{QUERY_STRING} state=([a-z0-9]+) 
RewriteRule ^(.*)$ http://%1.mydomain.com/$1 [L] 
1

E 'possibile che si fa il consenso e reindirizzato a un dominio pubblico da qualche parte che controlli (utilizzando tipo_accesso = offline) ?

Quando Google riprende il codice di autenticazione, non utilizzarlo dal dominio pubblico, passarlo con http webhook o qualcosa del tuo dominio privato che ha il vincolo, quindi effettuare lo scambio dal dominio privato. Questo ti consente quindi di utilizzare il dominio e l'url di richiamata in modo diverso per tutto ciò che desideri. Notare che il redirect_url impostato con lo script sdk deve essere uguale a quello impostato sulla console, indipendentemente dal server che si chiama effettivamente lo scambio e completare l'acquisizione del token.

Non sono sicuro se mi mancano i vostri vincoli ma forse questo aiuta.

3

Ciò che si desidera è utilizzare uno dei flussi di lavoro Oauth alternativi.

Se tutto ciò che si desidera è utilizzare il cloud di Google dal proprio servizio, andare per un account di servizio come spiegato qui: https://developers.google.com/console/help/new/#generatingoauth2 Ho questo lavoro su teowaki.com per interagire con google bigquery e funziona perfettamente. Tutto ciò che serve è generare una chiave sulla console cloud e posizionare la chiave sul server.

Se avete bisogno di identificare gli utenti, allora si può andare per l'OAuth per le applicazioni installate come mostrato qui https://developers.google.com/console/help/new/#generatingoauth2

In questo caso, è possibile scegliere beetween gli utenti che vanno a un URL in cui saranno presentati una token hanno bisogno di incollare di nuovo sulla vostra applicazione, o essere reindirizzati a un URL in localhost. Dato che presumo che tu stia facendo una webapp, dovresti scegliere la prima opzione e presentare agli utenti un token che devono incollare. Probabilmente non è la migliore UX di sempre, ma essendo un'applicazione interna è probabilmente fattibile.

+0

Ti ho assegnato il premio perché hai dato l'unica opzione che non richiede un dominio pubblico e questo è ovviamente il problema principale di questo problema. Sfortunatamente non aiuta molto il mio flusso di lavoro di sviluppo con la polvere, perché non vorrei un comportamento diverso in dev e in produzione, ma sono abbastanza sicuro che tu abbia risposto al problema di avere un server di produzione lan-only. – systho

+0

Grazie :) Hai ragione riguardo al comportamento diverso su dev/production. Ho pensato che fosse un'applicazione intranet, ecco perché ti ho fornito quella soluzione –

+0

E avevi ragione, ho appena aggiunto una nota con lo stesso problema con la polvere ma la nota era legata al messaggio di taglie che ora è scomparso – systho

Problemi correlati