Forum: Italian Ruby user group 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 Vipic 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 giorno 21/giu/2012, alle ore 11:08, Fabrizio Regini 
<freegenie@gmail.com> 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

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


> 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.

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 ;)

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 21/06/2012 11:24, Sante Rotondi 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 :P

ciao,
A.

2012/6/21 Andrea Pavoni <apeacox@gmail.com>:

> 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)

http://msdn.microsoft.com/it-it/magazine/hh708755.aspx

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!

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

Il giorno 21/giu/2012, alle ore 11:43, Andrea Pavoni <apeacox@gmail.com> 
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 :P
>
> 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 :)

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=... 
....>contenuto</a>

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.

On 21/giu/2012, at 12.01, Sante Rotondi 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 giorno 21/giu/2012, alle ore 12:10, Fabrizio Regini 
<freegenie@gmail.com> ha scritto:

>
> On 21/giu/2012, at 12.01, Sante Rotondi 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 
(http://www.securiteam.com/securityreviews/5WP0E2KFGK.html)

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 Rotondi wrote:

>  O peggio iniettare header nella risposta del tuo webserver e generare una 
response splitting (http://www.securiteam.com/securityreviews/5WP0E2KFGK.html)

Fantastico! Grazie!

-f

2012/6/21 Sante Rotondi <saten.r@gmail.com>

> 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 :)
>
>

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.

Il 21/06/2012 12:01, Sante Rotondi 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 :)

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 :P

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

2012/6/21 Andrea Pavoni <apeacox@gmail.com>

> 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.

Andrea Pavoni <apeacox@gmail.com> ha scritto:

> Il 21/06/2012 12:01, Sante Rotondi 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 :P
>
> 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.

>

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

https://github.com/rails/rails/blob/master/actionp...

Nonostante questo,  bene stare in guardia.

-f

2012/6/21 Sante Rotondi <saten.r@gmail.com>:
[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=... 
....>contenuto</a>
>
> 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:
http://armoredcode.com

Il giorno 21/giu/2012, alle ore 14:08, Paolo Perego 
<thesp0nge@gmail.com> ha scritto:

> Ciao Sante scusa ma dov' il XSS?

Sul sito malevolo. L'esempio del phishing era calzante.

>
> 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://)

D'accordo sul controllo da fare, ma penso che la vulnerabilit sia sul 
fatto che si possono craftare link e passarli alla vittima, piuttosto 
che modificare la richiesta asincrona per farsi redirigere altrove. 
Anche perch seguendo una richiesta ajax non cambi la location della 
window corrente.