Statistiche sui click ad un link

Salve a tutti,

Ho cercato una gemma che mi dica quanti click riceve un link e da quale
paese clicca e da quale IP e’ cliccato ma non l’ho trovata, qualcuno e’
stato più’ fortunato di me?

Devo per forza fare riferimento ad un software ad hoc ext alla app?

grazie a tutti e un saluto a tutti per lo splendido forum

C

Il 21/06/2012 03:42, Cluter V. ha scritto:

Ho cercato una gemma che mi dica quanti click riceve un link e da quale
paese clicca e da quale IP e’ cliccato ma non l’ho trovata, qualcuno e’
stato pi’ fortunato di me?

fondamentalmente, puoi tenere il conto dei click e degli IP come
preferisci,
sono informazioni disponibili nella request.

per la provenienza occorre un web service o database per fare
IP-geolocation, di
norma non gratis.

ciao,
A.

Farlo nella tua app di fatto abbastanza facile. Se parliamo di Rails,
quello di cui hai bisogno :

  1. una tabella del database con campi link e count (se vuoi anche
    referrer)
  2. un helper tipo link_to_with_tracking da usare al posto di link_to
    quando vuoi tracciare i click
  3. una action che si occupi di incrementare il conto dei click e fare
    redirect.

l’helper (2) manda alla action (3) con un parametro che contiene il link
effettivo.

Considera che dire ‘conto dei click’ con questa implementazione
abbanstanza insignificante visto che la action esposta al web, e con un
CURL chiunque pu incrementare il conto.Ovviamente questa la base, poi
devi pensare alla sicurezza a seconda dei tuoi bisogni. (cookies, domain
white lists, etc…)

Ciao,
-f

Il 21/06/2012 11:08, Fabrizio R. ha scritto:

  1. un helper tipo link_to_with_tracking da usare al posto di link_to quando
    vuoi tracciare i click
  2. una action che si occupi di incrementare il conto dei click e fare redirect.

l’helper (2) manda alla action (3) con un parametro che contiene il link
effettivo.

a prescindere dal db (credo che Redis pi indicato per queste cose), io
preferirei usare un before_filter da chiamare su controller e/o action.
rimane
pi semplice e generico da gestire.

un’altra soluzione pi sofisticata che non riguarda il codice dell’app,
potrebbe
essere quella di formattare ad-hoc i logs del webserver (apache o
nginx), poi li
leggi/analizzi in un secondo tempo.

ovviamente sono soluzioni spicciole e generiche, dipende da cosa si
vuole
ottenere :wink:

ciao,
A.

I redirect sono lenti, ma bindando una chiamata ajax al click non devi
sempre attendere la risposta dal servizio remoto prima di lasciare che
il browser cambi pagina?
Se non lo fai non potrebbe succedere che il browser non esegua la
chiamata ajax prima di cambiare pagina?

Grazie per l’osservazione sulla sicurezza, mi interessa. Ti posso
chiedere un esempio pratico?
Grazie mille,

-f

Il giorno 21/giu/2012, alle ore 11:08, Fabrizio R.
[email protected] ha scritto:

Ciao,
-f

No, vi prego, non lo fate…
Se non ci sono vincoli stringenti sul (non) uso di javascript, la
soluzione migliore tracciare i click bindando il click sui link con una
chiamata ajax che registra l’href e altri dati utili in modo asincrono.
Si pu anche fare una cosa analoga sui submit delle form. C’ della
documentazione utile se si cerca la guida per tracciare eventi con
google analytics.

Per quanto riguarda la veridicit e l’affidabilit dei dati raccolti, non
c’ modo di garantirsi da inquinamenti ( se ci pensate, anche su
analytics un utente malevolo pu generare tutti gli eventi che vuole e
sporcarvi le stat )

Evitate redirect! Sono lenti, vi costringono a passare un link cui
redirigere e quindi vi tocca validarlo o avete appena inserito un ottimo
punto per fare xss riflesso.

My two cents

2012/6/21 Andrea P. [email protected]:

per la provenienza occorre un web service o database per fare
IP-geolocation, di norma non gratis.

la gemma geoip usa il db di maxmind. C’ una versione free e una
versione non-free.
Purtroppo mentre funziona bene per alcune cose per altre prende
sbandate anche considerevoli (tendenzialmente il paese sempre
giusto, ma fastweb milano tende a risultare come torino, per dire)


twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: circleme.com

Grazie per l’osservazione sulla sicurezza, mi interessa. Ti posso chiedere un
esempio pratico?
Grazie mille,

From microsoft (dopo surface epic-fail mi fanno un po’ tristezza, dai
aiutiamoli a migliorare internet explorer)

Non so se l’esempio e’ esattamente calzante ma piu’ o meno .

Visto che non sono un esperto di XSS attacks ,sarei anche io curioso di
vedere un esempio pratico con il codice che registra il clicks in quest
esempio si parla di messaggi di stato ed injection di javascript

ciao!

Il 21/06/2012 11:24, Sante R. ha scritto:

Se non ci sono vincoli stringenti sul (non) uso di javascript, la soluzione
migliore tracciare i click bindando il click sui link con una chiamata ajax che
registra l’href e altri dati utili in modo asincrono. Si pu anche fare una cosa
analoga sui submit delle form. C’ della documentazione utile se si cerca la guida
per tracciare eventi con google analytics.

anche questa soluzione credo sia pittosto lenta (click sul link -> ajax
->
segui link), non trovi? a prescindere dal fatto che JS lavora in modo
asincrono,
questa soluzione significa raddoppiare le richieste sul server, tranne
nel caso
in cui usi un’app separata per trackare i clicks :stuck_out_tongue:

ciao,
A.

+1 per GeoIP, non fai richieste esterne e le performance rimanogno
prevedibili.

Il giorno 21/giu/2012, alle ore 11:43, Andrea P. [email protected]
ha scritto:

anche questa soluzione credo sia pittosto lenta (click sul link → ajax → segui
link), non trovi? a prescindere dal fatto che JS lavora in modo asincrono, questa
soluzione significa raddoppiare le richieste sul server, tranne nel caso in cui
usi un’app separata per trackare i clicks :stuck_out_tongue:

ciao,
A.

Bisogna sempre considerare quanto accurata vuole essere la raccolta del
dato, tenendo conto che sono pur sempre dati pilotabili (uno spider o
crawler seguirebbe i link che portano ad un redirect, ma difficilmente
ha un motore js per triggerare gli eventi ajax)

La redirezione con salvataggio del dato asincrona pi veloce, perch
fatta la richiesta ajax all’azione che salva il click si pu seguire il
link senza attendere la risposta dal server ( trade off di certezza
della registrazione del click con preziosi millisecondi del tempo
dell’utente ). La redirezione per definizione sincrona e quindi ti
perdi l’ottimizzazione giocata sulla probabilit di successo.

Inoltre la parte con le form totalmente infattibile con la redirezione.
Non puoi redirigere se non in Get, quindi se volessi registrare e
proseguire dovresti ricreare la form originale in una pagina ad hoc
(renderizzata come risposta al salvataggio della statistica) e
submittarla in automatico. Io dico di non farlo :slight_smile:

Rispondo anche a Fabrizio con un esempio di xss su redirezione.

Tu hai un link, con il sistema a redirect, fatto circa cos:
<a
href=“http://dominio.it/track?url=url_corrente&next_url=dove_redirigere
…>contenuto

Se io creo un link con next_url=sitomalevolo e lo mando ad un tuo utente
posso fare di lui ci che voglio, e lo faccio con la piena legittimit ai
suoi occhi di un link che punta al tuo dominio.

Il giorno 21/giu/2012, alle ore 12:10, Fabrizio R.
[email protected] ha scritto:

On 21/giu/2012, at 12.01, Sante R. wrote:

posso fare di lui ci che voglio,

Cavolo, suona brutto. Sinceramente per non capisco e ammetto di non essere un
guru di sicurezza informatica. Per quanto ne so l’unico problema potrebbe essere
il phishing. Insomma sto facendo una GET ad un altro dominio. L’unica cosa che
arriva del dominio originale, ovvero del tuo sito, HTTP_REFERER.

Mi perdo qualcosa?

  • f

Il phishing gi un problema notevole, ma a seconda di come ti comporti
nel controller che fa la redirezione potrebbe essere possibile anche
redirigere ad una pagina interna del sito originale, facendo poi
eseguire javascript all’interno di questa. O peggio iniettare header
nella risposta del tuo webserver e generare una response splitting
(Vulnerability Security Testing & DAST | Fortra's Beyond Security)

Per caritsi pu mettere una toppa a tutto, ma io dico che nel 99% dei
nostri use case tutto ci overkill e conviene appiggiarsi a chi fa gi
bene il task originale, ossia raccogliere statistiche.

Io consiglio woopra oltre al solito analytics

On 21/giu/2012, at 12.17, Sante R. wrote:

O peggio iniettare header nella risposta del tuo webserver e generare una
response splitting (Vulnerability Security Testing & DAST | Fortra's Beyond Security)

Fantastico! Grazie!

-f

On 21/giu/2012, at 12.01, Sante R. wrote:

posso fare di lui ci che voglio,

Cavolo, suona brutto. Sinceramente per non capisco e ammetto di non
essere un guru di sicurezza informatica. Per quanto ne so l’unico
problema potrebbe essere il phishing. Insomma sto facendo una GET ad un
altro dominio. L’unica cosa che arriva del dominio originale, ovvero del
tuo sito, HTTP_REFERER.

Mi perdo qualcosa?

  • f

2012/6/21 Sante R. [email protected]

La redirezione per definizione sincrona e quindi ti perdi
l’ottimizzazione giocata sulla probabilit di successo.

Inoltre la parte con le form totalmente infattibile con la redirezione.
Non puoi redirigere se non in Get, quindi se volessi registrare e
proseguire dovresti ricreare la form originale in una pagina ad hoc
(renderizzata come risposta al salvataggio della statistica) e submittarla
in automatico. Io dico di non farlo :slight_smile:

Scusate se sto dicendo un mare di castronerie, ma se siamo in rails,
quindi
RestFULL non possibile spostare il tracking dei click sui controller?
Se
non sto prendendo un abbaglio micidiale si potrebbe risolvere con un
befor_filter su action specifiche sulle risorse… devo fare Harakiri?
^^

Oltretutto ultimamente mi sto dilettando con Rack, visto che Rails Rack
based dovrebbe esser possibile inserire un middleware per le statistiche
in
modo trasparente, ho fatto una ricerca veloce e non ho trovato molto
(diverse gemme implementavano il traking su google analitics) devo
approfondire.


Riccardo

L’esperienza quello che ottieni quando, non ottieni quello che
desideri.

2012/6/21 Andrea P. [email protected]

sulla parte JS/ajax, la mia perplessit riguardava due aspetti:

  • l’effettiva registrazione del click (proprio perch, salvo accorgimenti,
    sarebbe tutto asincrono)
  • la doppia richiesta al server per ciascun click, almeno nel caso in cui
    si stia usando la stessa app

Ecco, mi hai risposto ^^


Riccardo

L’esperienza quello che ottieni quando, non ottieni quello che
desideri.

Il 21/06/2012 12:01, Sante R. ha scritto:

Bisogna sempre considerare quanto accurata vuole essere la raccolta del dato,
tenendo conto che sono pur sempre dati pilotabili (uno spider o crawler seguirebbe
i link che portano ad un redirect, ma difficilmente ha un motore js per triggerare
gli eventi ajax)

La redirezione con salvataggio del dato asincrona pi veloce, perch fatta la
richiesta ajax all’azione che salva il click si pu seguire il link senza attendere
la risposta dal server ( trade off di certezza della registrazione del click con
preziosi millisecondi del tempo dell’utente ). La redirezione per definizione
sincrona e quindi ti perdi l’ottimizzazione giocata sulla probabilit di successo.

Inoltre la parte con le form totalmente infattibile con la redirezione. Non
puoi redirigere se non in Get, quindi se volessi registrare e proseguire dovresti
ricreare la form originale in una pagina ad hoc (renderizzata come risposta al
salvataggio della statistica) e submittarla in automatico. Io dico di non farlo :slight_smile:

assolutamente daccordo con te riguardo i redirects. infatti la soluzione
che ho
proposto non usa redirect, bens un before_filter (o volendo un
middleware con
rack o custom logs del web server da processare in un secondo tempo).
quindi
ogni richiesta viene trackata sempre e comunque. poi vero che verranno
registrati anche i clicks di uno spider/crawler, ma qui rientriamo sul
discorso
dell’accuratezza dei dati :stuck_out_tongue:

sulla parte JS/ajax, la mia perplessit riguardava due aspetti:

  • l’effettiva registrazione del click (proprio perch, salvo
    accorgimenti,
    sarebbe tutto asincrono)
  • la doppia richiesta al server per ciascun click, almeno nel caso in
    cui si
    stia usando la stessa app

Andrea P. [email protected] ha scritto:

Il 21/06/2012 12:01, Sante R. ha scritto:

assolutamente daccordo con te riguardo i redirects. infatti la soluzione che ho
proposto non usa redirect, bens un before_filter (o volendo un middleware con rack
o custom logs del web server da processare in un secondo tempo). quindi ogni
richiesta viene trackata sempre e comunque. poi vero che verranno registrati
anche i clicks di uno spider/crawler, ma qui rientriamo sul discorso
dell’accuratezza dei dati :stuck_out_tongue:

sulla parte JS/ajax, la mia perplessit riguardava due aspetti:

  • l’effettiva registrazione del click (proprio perch, salvo accorgimenti,
    sarebbe tutto asincrono)

Tipicamente si inserisce un timer che d un 50ms di tempo alla chiamata
ajax prima dinseguire il link, se si vuole si pu anche rendere la
chiamata sincrona o riprovare prima di seguire il link

  • la doppia richiesta al server per ciascun click, almeno nel caso in cui si
    stia usando la stessa app
    Vero, ma tendezialmente sono due richieste diverse. Una delle due sar
    molto veloce, registra solo i dati, l’altra c’era gi

Also, un before filter va bene solo se si tracciano soltanto i link
interni.

2012/6/21 Sante R. [email protected]:
[snip]

Rispondo anche a Fabrizio con un esempio di xss su redirezione.

Tu hai un link, con il sistema a redirect, fatto circa cos:
<a href=“http://dominio.it/track?url=url_corrente&next_url=dove_redirigere
…>contenuto

Se io creo un link con next_url=sitomalevolo e lo mando ad un tuo utente posso
fare di lui ci che voglio, e lo faccio con la piena legittimit ai suoi occhi di un
link che punta al tuo dominio.
Ciao Sante scusa ma dov’ il XSS?

L’unico pericolo di security che vedo qui :

  • parte la richiesta asincrona dal browser dell’attaccante
  • l’attaccante la blocca con un proxy applicativo e cambia next_url
  • l’attaccante si fa redirigere ovunque, se e solo se nel controller
    non vengono fatti controlli sul fatto che next_url possa essere solo
    una url relativa e non una url assoluta (HINT: aggiungi ai controlli
    una regex nel tuo controller che non serve la richiesta se next_url
    inizia con http:// o https://)

Ciao

$ cd /pub
$ more beer

The blog that fills the gap between appsec and developers:

Per onore di cronaca, penso che con Rails siamo protetti sul tema del
giustamente citato HTTP Response Splitting:

Nonostante questo, bene stare in guardia.

-f