servlet URL resirect

[sydbarrett]

Salve,
il problema da risolvere è il seguente:
ho una web application che gestisce gli accessi ad un data risorsa web attraverso una coda FIFO. I clients devono accedere a questa risorsa web(pagina con un dato URL) ESCLUSIVAMENTE attraverso la coda.
Per tenere nascosto l'URL ed evitare che i clients accedessero all' url della risorsa da nascondere bypassando la coda ho, ingenuamente, disposto la visualizzazione in un IFRAME interno alla pagina principale dell'applicazione. Purtroppo, è facile ricavare l'URL: basta che l'utente usi firbug oppure con IE bastano due clic sull' IFRAME per visualizzare le proprietà della pagina e quindi l'url che volevo nascondere
In definitiva, sembra che non ci sia modo di nascondere l'URL perchè il browser , in qualche modo, comunque fa l'introspezione in HTTP.


Ho pensato che un modo per risolverlo, sarebbe quello di configurare gli accessi al server della risorsa da nascondere,PERMETTENDO L'ACCESSO ESCLUSIVAMENTE AD UN UNICO INDIRIZZO IP (chiamato X) cioè quello di un server PROXY.

Come PROXY utilizzerei una servlet che funzionerebbe così:

1) arriva una request da un client con IP Y.
2) La servlet PROXY, sostituisce Y con X (fa uno spoofing!)
3) La servlet PROXY tramite una "redirect" chiede la URL da nascondere, facendo credere che sia partita da X (grazie al passo precedente) ma restituisce la pagina web a Y.

Il browser del client con IP=Y vede l'url da nascondere in chiaro ma anche se tenta di accedervi direttamente(quindi non attraverso la servlet proxy)non riesce perchè filtrata dal server.

Spero di essere stato chiaro, non so se sia un problema facilmente risolvibile.
In particolare sarebbe interessante capire come implementare il passo 2)

GRAZIE

[unomichisiada]

Originariamente inviato da sydbarrett
Salve,
il problema da risolvere è il seguente:
ho una web application che gestisce gli accessi ad un data risorsa web attraverso una coda FIFO. I clients devono accedere a questa risorsa web(pagina con un dato URL) ESCLUSIVAMENTE attraverso la coda.
Per tenere nascosto l'URL ed evitare che i clients accedessero all' url della risorsa da nascondere bypassando la coda ho, ingenuamente, disposto la visualizzazione in un IFRAME interno alla pagina principale dell'applicazione. Purtroppo, è facile ricavare l'URL: basta che l'utente usi firbug oppure con IE bastano due clic sull' IFRAME per visualizzare le proprietà della pagina e quindi l'url che volevo nascondere
In definitiva, sembra che non ci sia modo di nascondere l'URL perchè il browser , in qualche modo, comunque fa l'introspezione in HTTP.


Ho pensato che un modo per risolverlo, sarebbe quello di configurare gli accessi al server della risorsa da nascondere,PERMETTENDO L'ACCESSO ESCLUSIVAMENTE AD UN UNICO INDIRIZZO IP (chiamato X) cioè quello di un server PROXY.

Come PROXY utilizzerei una servlet che funzionerebbe così:

1) arriva una request da un client con IP Y.
2) La servlet PROXY, sostituisce Y con X (fa uno spoofing!)
3) La servlet PROXY tramite una "redirect" chiede la URL da nascondere, facendo credere che sia partita da X (grazie al passo precedente) ma restituisce la pagina web a Y.

Il browser del client con IP=Y vede l'url da nascondere in chiaro ma anche se tenta di accedervi direttamente(quindi non attraverso la servlet proxy)non riesce perchè filtrata dal server.

Spero di essere stato chiaro, non so se sia un problema facilmente risolvibile.
In particolare sarebbe interessante capire come implementare il passo 2)

GRAZIE

C'è una cosa che va chiarita:
questa famigerata "risorsa web" la gestisci tu e quindi la puoi esporre o meno su ip pubblico a tuo piacimento, oppure è una risorsa di terze parti che è già di per se in internet (intendendo su ip pubblico) ?
Nel secondo caso non c'è ovviamente nulla che tu possa fare per nascondere la cosiddetta url, se qualcuno la becca, anche a prescindere dal tuo applicativo (o portale che sia), ci accede e basta. Fammi un po' capire sta cosa prima.
Nel primo caso , mi interessa anche capire di che tipo di risorsa si tratta se possibile.

[sydbarrett]

Grazie per la risposta...ormai non ci contavo più

Son ben contento di spiegarti:
dalla tua risposta mi sembra, che hai compreso il cuore del problema, e per completezza ti dico che la "risorsa web" altri non è che un esperimento di laboratorio elettronico realizzato con LabVIEW(software propietario adatto allo scopo).

Questa risorsa è dunque è un pannello virtuale con manopole, cursori controllabili da remoto. Ovviamente non è esportabile così come è, ed occorre ingegnarsi in qualche modo. La soluzione adottata è il pannello, in esecuzione su una macchina win xp, "incapsulato" nel tool TightVNC JAVAviewer sulla stessa macchina; questo tool rende VNC server controllabile da remoto via HTTP sulla porta server (di default) 5800. Per cui l'indirizzo della famigerata risorsa web è ad esempio http:\\143.22.34.167:5800.

La questione che poni è interessente: NON DEVO NECESSARIAMENTE ESPORRE PUBBLICAMENTE LA RISORSA per cui, collegando VIA LAN il mio server proxy al server della risorsa avrei un indirizzo tipo http:\\192.168.0.1:5800. Però poi questo , tramite NAT o qualcos'altro deve essere ridirezionato dalla servlet sull' IFRAME del client. A questo punto il client vedrà un url sull'iframe che per lui è irrangiungibile direttamente..


Che ne pensi? E' una soluzione tecnicamente fattibile? Oppure è un delirio da sovraesposizione allo studio?

Grazie e spero tu possa rispondermi presto

[unomichisiada]

Originariamente inviato da sydbarrett
Grazie per la risposta...ormai non ci contavo più

Son ben contento di spiegarti:
dalla tua risposta mi sembra, che hai compreso il cuore del problema, e per completezza ti dico che la "risorsa web" altri non è che un esperimento di laboratorio elettronico realizzato con LabVIEW(software propietario adatto allo scopo).

Questa risorsa è dunque è un pannello virtuale con manopole, cursori controllabili da remoto. Ovviamente non è esportabile così come è, ed occorre ingegnarsi in qualche modo. La soluzione adottata è il pannello, in esecuzione su una macchina win xp, "incapsulato" nel tool TightVNC JAVAviewer sulla stessa macchina; questo tool rende VNC server controllabile da remoto via HTTP sulla porta server (di default) 5800. Per cui l'indirizzo della famigerata risorsa web è ad esempio http:\\143.22.34.167:5800.

La questione che poni è interessente: NON DEVO NECESSARIAMENTE ESPORRE PUBBLICAMENTE LA RISORSA per cui, collegando VIA LAN il mio server proxy al server della risorsa avrei un indirizzo tipo http:\\192.168.0.1:5800. Però poi questo , tramite NAT o qualcos'altro deve essere ridirezionato dalla servlet sull' IFRAME del client. A questo punto il client vedrà un url sull'iframe che per lui è irrangiungibile direttamente..


Che ne pensi? E' una soluzione tecnicamente fattibile? Oppure è un delirio da sovraesposizione allo studio?

Grazie e spero tu possa rispondermi presto

Sebbene si esca OT rispetto al forum java, a mio avviso l'uso di una servlet in java non è la soluzione migliore per risolvere il tuo problema specifico. Io userei un bell'apache (esposto in pubblico mediante configurazione sul tuo router , a questo punto credo tu ne abbia la possibilità)) configurato per agire da proxy. Una cosa molto simile a quanto viene illustrato qui . Leggi un po' e fammi sapere come va. Ciao

[sydbarrett]

Ti ringrazio per il prezioso suggerimento.

Uscire fuori tema, e su questo concorderai, è facile quando certi problemi richiedono soluzioni complesse afferenti tecnologie diverse.

Ho letto l'articolo ed effettivamente quella del proxy Apache sembra la strada maestra da percorrere. In ogni caso, la gestione delle code è gia stata implementata tramite un modello di dispatching realizzato con le Servlet all'interno del container Tomcat.
L'applicazione deve essere in esecuzione in un dipartimento universitario,per cui devo necessariamente connettere apache a Tomcat.

Devo approfondire e verificare se anche una risorsa server autonoma come quella associata a tightVNC all'indirizzo http:\\ipAddr:5800 può essere gestita tramite redirect da Apache proxy.

Ti ringrazio e ti aggiorno sull'evolversi della questione sempre su questo topic.

Ciao

[unomichisiada]

Originariamente inviato da sydbarrett
Ti ringrazio per il prezioso suggerimento.

Uscire fuori tema, e su questo concorderai, è facile quando certi problemi richiedono soluzioni complesse afferenti tecnologie diverse.

Ho letto l'articolo ed effettivamente quella del proxy Apache sembra la strada maestra da percorrere. In ogni caso, la gestione delle code è gia stata implementata tramite un modello di dispatching realizzato con le Servlet all'interno del container Tomcat.
L'applicazione deve essere in esecuzione in un dipartimento universitario,per cui devo necessariamente connettere apache a Tomcat.

Devo approfondire e verificare se anche una risorsa server autonoma come quella associata a tightVNC all'indirizzo http:\\ipAddr:5800 può essere gestita tramite redirect da Apache proxy.

Ti ringrazio e ti aggiorno sull'evolversi della questione sempre su questo topic.

Ciao

Capisco. Se devi per forza passare per una servlet, allora puoi fare in modo che lei (o un altra nella tua ebapp) faccia da proxy facendo delle chiamate server to server (in cui la tua servlet contatta il pannello) e restituendo il risultato sulle response verso il client. Naturalmente considerando la presenza di eventuali css , immagini eccetera all'interno della pagina da "proxare", non è immediato scrivere il codice per farlo. Esiste anche qualcosa di già pronto qui . Mi è capitato di usare questa piccola libreria per gestire una situazione simile alla tua. In particolare avevo delle risorse (video in flash e pdf) servite da una webapplication sulla rete privata e dovevo renderle disponibili all'esterno (in pubblico) ma mantenerle sotto la stessa autenticazione della mia webapp principale (quindi solo alcuni utenti, previo login, potevano vedere le risorse in questione) . Dai uno sguardo pure a quella eventualmente.

[sydbarrett]

Avevo già scaricato il .zip (non il jar come indicato nel sito) ed ho inserito le classi nella libreria della mia applicazione nonchè aggiornato il file web.xml. Tuttavia non ho approfondito perchè non sono documentate e non ci sono i sorgenti.

A tal proposito vorrei chiederti come le hai utilizzate:

1) Hai istanziato oppure esteso la classe HttpProxyServlet?
2) Hai triovato la documentazione, oppure hai smanettato un pò prima di usarle?
3) Eventualmente, se possibile, potresti suggerirmi come l'hai implementata?

Grazie

[unomichisiada]

Originariamente inviato da sydbarrett
Avevo già scaricato il .zip (non il jar come indicato nel sito) ed ho inserito le classi nella libreria della mia applicazione nonchè aggiornato il file web.xml. Tuttavia non ho approfondito perchè non sono documentate e non ci sono i sorgenti.

A tal proposito vorrei chiederti come le hai utilizzate:

1) Hai istanziato oppure esteso la classe HttpProxyServlet?
2) Hai triovato la documentazione, oppure hai smanettato un pò prima di usarle?
3) Eventualmente, se possibile, potresti suggerirmi come l'hai implementata?

Grazie

La documentazione è effettivamente piuttosto scarna e la libreria non fornisce i sorgenti effettivamente, ma fa comunque in maniera egregia il lavoro, e i pochi esempi che trovi qui sono abbastanza chiari. Ti risponderò per punti:

1) Non è stato necessario estenderla ne istanziarla implicitamente, è sufficiente che la libreria sia nel classpath della web application e configurare la servlet HttpProxyServlet nel web.xml.
2) Ho solo visto quegli esempi e fatto qualche prova
3) Come da punto 1, non ho implementato nulla, semplicemente ho fatto qualcosa del tipo:

<servlet>
  <servlet-name>HttpProxy</servlet-name>
  <servlet-class>com.jsos.httpproxy.HttpProxyServlet</servlet-class>
<init-param>
  <param-name>host</param-name>
  <param-value>http://host/o/meglio/url/cui/reindirizzare/la/chiamata</param-value>
</init-param>
</servlet>

e sempre nel web.xml

<servlet-mapping>
  <servlet-name>HttpProxy</servlet-name>
  <url-pattern>/url/pattern/del/tipo/di/request/da/intercettare</url-pattern>
</servlet-mapping>

In questo modo ogni chiamata alla mia webapplication del tipo:

http://miohost/miawebapp/url/pattern...metro2=valore2

viene rediretta automaticamente su

http://host/o/meglio/url/cui/reindir...metro2=valore2

e la risposta ottenuta restituita a chi ha invocato la prima url

Nel tuo caso però la situazione è un po diversa, mentre io avevo solo necessità di mettere sotto autenticazione la "url nascosta", cosa che facevo mediante dei filtri, tu hai necessità di implementare questo accesso FIFO, quindi probabilmente la cosa migliore è che tu estenda la servlet HttpProxyServlet in modo da sfruttarla per la funzionalità di proxy e poi implementi nella subclasse la funzionalità di accesso FIFO. Ovviamente nel web.xml in luogo della com.jsos.httpproxy.HttpProxyServlet dovrai inserire la tua sublclasse.

[sydbarrett]

Sono finalmente riuscito ad utilizzare queste classi, ed in generale risolvono il tipo di problema in cui io mi sto imbattendo.
In particolare:

1)occorro tante servlet che ereditano da HttpProxyServlet quante sono le code da gestire.
2)Ognuna di esse ha il parametro host configurato con la resource Url da utilizzare.
3)Quando sono invocate dall'interno dell'applicazione(tramite Ajax) ricevono una password generata all'interno dell'applicazione stessa (la password può essere un valore di un attributo creato adhoc per la servlet proxy) all' interno della servlet proxy la password viene resettata. Così chi le invoca dall'esterno riceve un forbidden

Il fatto di istanziare più servlet ereditate è necessario perchè non si può modificare a run time l'init parameter.


In ogni caso ho una difficoltà dovuta al tipo di risorsa web che deve chiedere attraverso il parametro host. Purtroppo la mia risorsa è incapsulata in un'applet Java che si trova all'interno di TightVNC. Quando viene richiesta tramite il proxy ho un errore di runtime Java e l'applet non si vede, fra l'altro i sorgenti di quest'applet in VNC non sono disponibili

Quando le hai utilizzate tu hai riscontrato qualche problema del genere?

Ti ringrazio al solito per i tuoi preziosi consigli e suggerimenti

Ciao e a presto

[unomichisiada]

Originariamente inviato da sydbarrett
1)occorro tante servlet che ereditano da HttpProxyServlet quante sono le code da gestire.
2)Ognuna di esse ha il parametro host configurato con la resource Url da utilizzare.
3)Quando sono invocate dall'interno dell'applicazione(tramite Ajax) ricevono una password generata all'interno dell'applicazione stessa (la password può essere un valore di un attributo creato adhoc per la servlet proxy) all' interno della servlet proxy la password viene resettata. Così chi le invoca dall'esterno riceve un forbidden

Il fatto di istanziare più servlet ereditate è necessario perchè non si può modificare a run time l'init parameter.


In ogni caso ho una difficoltà dovuta al tipo di risorsa web che deve chiedere attraverso il parametro host. Purtroppo la mia risorsa è incapsulata in un'applet Java che si trova all'interno di TightVNC. Quando viene richiesta tramite il proxy ho un errore di runtime Java e l'applet non si vede, fra l'altro i sorgenti di quest'applet in VNC non sono disponibili

Quando le hai utilizzate tu hai riscontrato qualche problema del genere?

Ti ringrazio al solito per i tuoi preziosi consigli e suggerimenti

Ciao e a presto

1)Non avevo capito che ci fossero più code da gestire, finora hai sempre parlato di una sola coda che gestisce le richieste nell'ordine di arrivo.
2)Diretta conseguenza del punto uno, ma non è comunque un problema usare più istanze della stessa servlet...è uno oggetto java come gli altri
3) non ho assolutamente capito questa faccenda delle chiamate ajax, non corrisponde per nulla allo scenario che mi hai descritto finora

Per quanto concerne il modificare a runtime l'init parameter, se usi la libreria così com'è ti do ragione, ma (e io non ti ho detto nulla ) il codice della libreria non è offuscato e puoi agire di conseguenza, ci sono stato costretto anche io per piegarlo al mio volere quando dovevo soddisfare una certa esigenza di maggiore dinamicità. Purtroppo la libreria è un po' blindata da punto di vista della possibilità di personalizzarla per sublcassing ed ho dovuto "giocare sporco". Non mi chiedere delucidazioni in merito, almeno non qui sul forum, perché non è (giustamente) un argomento molto ben visto il reverse engineering

Non mi è capitato di far passare delle applet attraverso il proxy ma come ti ho detto mi è capitato di farci passare dei flash, che dfunzionano perfettamente. Non so...indaga un po'. In ogni modo mi pare TightVNC metta tranquillamente a disposizione i sorgenti, anche del viewer in java, quindi non capisco perché tu dica il contrario. link