Sid sessioni seo

[Uno]

Sto ragionando su una cosa.
Siccome non mi piacciono le sessioni del php e comunque non risolverebbero il problema che mi pongo, sto lavorando ad un mio sistema di sessioni.
Perchè posto qui piuttosto che in programmazione?
Perchè il problema nasce proprio dal discorso Seo, come programmazione non ce ne sarebbero.
Se fosse per me farei una cosa classica, cookie solo per il sid e memorizzazione in db della sessione vera e propria. Cosa che potrebbe essere fatta anche con le sessioni native tra l'altro.
Il problema nasce per chi disattiva i cookies (o per navigazioni che non ne prevedono tipo spider). La soluzione standard prevede il sid nell'url, ma se voglio usare url friendly puliti i motori (ok parlo di google visto che è quello che prendiamo sempre più in considerazione) non capiscono più di togliere il sid e si trovano con tante pagine dall'url diverso e contenuti uguali.
Quindi di solito il sid sull'url si disattiva a prescindere dove ci sono gli url friendly.
Con gli utenti registrati il problema non si pone, o gli si fa presente che se non abilitano i cookies non possono rimanere loggati, o si aggiunge il sid solo ai registrati.
Però mi secca non poter tenere una sessione con chi non loggato non ha i coockie abilitati. (statistiche, carrelli etc)
Tra l'altro i coockies con IE7 e IE8 a volte fanno i capricci perchè IE ha deciso di diventare sicuro limitando la libertà di chi non sa come impostarsi il browser.

Ho pensato anche di riscrivere dinamicamente i link all'interno di form potendo così passare il sid tramite post, ma a parte che stavo facendo delle prove per l'accessibilità non mi entusiasma molto l'idea.

C'è qualcun altro che si è mai posto questi problemi o sono l'unico?

[Antonio]

Penso ci sia poco da fare se non vuoi usare i biscottini o l'inject del SID nell'URL.

Mi era venuto in mente qualcosa di perverso da fare con javascript, ma poi il problema lo sposti a livello JS (se ti bloccano il/i JS cosa fai?).

Te la butto lì:
SID salvato in una variabile js (naturalmente dopo averlo generato lato server);
JS che si occupa all'evento onclick sul link di aggiungere il SID al link.

In questo caso:
- gli spider, non eseguendo il js, si troverebbero con il link pulito e "statico"
- gli utenti non loggati allergici ai biscottini avrebbero le loro belle sessioni
- gli utenti non loggati, allergici ai biscottini ed ai js la farebbero franca.

Qui sorge un altro problema poi lato SEO: i link inseriti sugli altri siti, che portano al tuo, e che hanno al loro interno il SID di un utente che ha copiato paro paro l'url e che potrebbero essere seguiti da uno spider.

Volendo porre una pezza al problema, postresti fare questo controllo del SID:
- se la sessione è scaduta fare un redirect 302 alla pagina senza SID nell'url;
- se l'ip del visitatore è diverso da quello registrato fare un redirect 302 alla pagina senza SID nell'url.

Non è elegante e non è che mi piaccia come soluzione, ma è l'unica cosa che mi è venuta in mente.

[Uno]

Eh con javascript si può fare in diversi modi, ma siamo da capo.

Quasi quasi sto pensando di usare l'IP e i dati browser etc per tenere la sessione (se non funzionano i cookies) quando uno non è loggato e poi quando uno si logga posso passare tranquillamente a cookie o sid.
Tanto quando uno non è loggato i dati che posso tenere in sessione (esempio un carrello) sono solo di comodo, non sensibili.

Ci penso ancora, se a qualcuno viene una idea (sarà dura, c'è poco da fare)

[Antonio]

Quasi quasi sto pensando di usare l'IP e i dati browser etc per tenere la sessione (se non funzionano i cookies) quando uno non è loggato...

Il problema è chi esce con stesso IP, metti gli utenti fastweb ad es., il rischio di assegnare a più utenti la stessa sessione è alto (utenti che che escono con lo stesso ip, broswer, SO).
Se poi pensiamo alle intranet aziendali è ancora peggio, dato che le conf dei vari pc di solito sono pressoché identiche

[ale]

Il problema è chi esce con stesso IP, metti gli utenti fastweb ad es., il rischio di assegnare a più utenti la stessa sessione è alto (utenti che che escono con lo stesso ip, broswer, SO).
Se poi pensiamo alle intranet aziendali è ancora peggio, dato che le conf dei vari pc di solito sono pressoché identiche

Oppure l'altra possibilità di questi che sono dietro un cluster di proxy con diversi IP.

[Uno]

Avete ragione anche voi, tenerle così per quanto non importanti equivale a non tenerle.

Quindi al limite mi conviene tenere le sessioni solo per chi ha i cookies abilitati (se uno usa un carrello e non prende il coockie lo avviso o passo al sid).
L'unico handicapp, a quanto ne so, è che se non uso il sid (ci sono parecchi che lo fanno) sull'url potrei anche beccare l'utente che non riesce a loggarsi, per esempio con cellulari e simili.
A voi come risulta la situazione? So che parecchi browser di cellulari oggi accettano i cookies.

Mettere ogni link dentro un form post con sid in campo hidden pare brutto vero?

Ieri per sfizio ho provato a loggarmi in Yahoo senza cookie, mi dice che non posso e che devo abilitarli. Vbulletin invece aggiunge il sid sull'url, anche sulla versione 4 che ha un urlrewrite (che sarebbe da ripulire in htaccess). Le versioni prima della 4 se hanno vbseo aggiunge il sid sull'url solo se ci si logga senza cookie (testato qui).

Mi sa che l'unica è aggiungere il sid se i coockie non sono abilitati, non c'è scampo a meno di non chiamarsi Yahoo e simili.
O il famoso form-post-campo_hidden, ma non mi piace (lo proverò comunque su browser solo testo per vedere che esce)

[Uno]

Antò, Ale ma secondo voi (o chi altri fosse interessato) i motori di ricerca seguirebbero un simil-link passato tramite form?
Se no per essere sicuro mi toccherebbe fare due paginette di test e vedere se mi indicizza la seconda..

Però bisognerebbe pure provare un software di scansione per ipovedenti come legge il form (non ho idea) se ogni link la voce metallica gli legge form... pulsante "entra" (avanti o nome contenuto) non si può fare....
Ad occhio penso che distingua, sul browser solo testo non compare tutto il form, solo la parola da cliccare come se fosse un link.

[Antonio]

Antò, Ale ma secondo voi (o chi altri fosse interessato) i motori di ricerca seguirebbero un simil-link passato tramite form?
Se no per essere sicuro mi toccherebbe fare due paginette di test e vedere se mi indicizza la seconda..

Però bisognerebbe pure provare un software di scansione per ipovedenti come legge il form (non ho idea) se ogni link la voce metallica gli legge form... pulsante "entra" (avanti o nome contenuto) non si può fare....
Ad occhio penso che distingua, sul browser solo testo non compare tutto il form, solo la parola da cliccare come se fosse un link.

Se il campo è hidden, è hidden anche per i lettori testuali ed i browser testuali.

Dovrebbero essere letti solo i campi di input (per digitare ad es. nome e cognome) ed il nome del pulsante submit per fare l'invio dei dati.

Però non ho capito una cosa, tu vorresti trasformare tutti i links in form? Mi sembra veramente un pastrocchio

[Uno]

Se il campo è hidden, è hidden anche per i lettori testuali ed i browser testuali.

Dovrebbero essere letti solo i campi di input (per digitare ad es. nome e cognome) ed il nome del pulsante submit per fare l'invio dei dati.

Però non ho capito una cosa, tu vorresti trasformare tutti i links in form? Mi sembra veramente un pastrocchio

Si si quello rimarrebbe nascosto ma andrebbe bene così
Quello che mi interesserebbe sarebbe quello di invio del form, cioè che sostituirebbe il link.

Si lo so che pare strano, ma tutto sommato potrebbe (dico potrebbe, bisognerebbe verificare tutto quello che scrivevo sopra) una soluzione accessibile ed invisibile (non nel senso di sicurezza ovviamente quello è un'altro discorso) visivamente a tutti anche se hanno js e cookie disabilitati.

Parsare i link e trasformarli in form usando php sarebbe facile e trasparente

[ale]

Antò, Ale ma secondo voi (o chi altri fosse interessato) i motori di ricerca seguirebbero un simil-link passato tramite form?
Se no per essere sicuro mi toccherebbe fare due paginette di test e vedere se mi indicizza la seconda..

Credo che sia improbabile che un motore di ricerca stia seguendo un form tramite POST con tutti i campi e direi pure neanche solo tramite GET, non sarebbe molto sensato.

[Uno]

Credo che sia improbabile che un motore di ricerca stia seguendo un form tramite POST con tutti i campi e direi pure neanche solo tramite GET, non sarebbe molto sensato.

Sono d'accordo con te che non sarebbe molto sensato ma ti basterebbe vedere quanti spiders tentano di loggarsi da me

A me però interessa Google, Yahoo ed i principali. In mancanza di letteratura in merito l'unica sarebbe provare.
Se funzionasse alla fine sarebbe pure più comodo che prevedere tutte le casistiche anche se ammetto che trasformare i link in form non piace al mio ordine mentale

[luca9898]

Ultimamente GOOGLE ci viene incontro con una serie di strumenti per superare questo annoso problema dei SID.

Se lo risolvi alla radice con la programmazione è meglio.
Altrimenti leggi questo post ufficiale di GOOGLE http://googlewebmastercentral.blogsp...lps-with.html:

With the "Parameter Handling" setting, you can now provide suggestions to our crawler to ignore the parameters category, trackingid, and sessionid. If we take your suggestion into account, the net result will be a more efficient crawl of your site, and fewer duplicate URLs.

In pratica puoi usare i SID che poi GOOGLE non legge se (meglio farli tutti):
- Ci fai una bella SITEMAP.xml con le URL pulite
- Ci metti il rel="canonical" (su ogni pagina) per indicare a GOOGLE quali sono le URL ufficiali
- Usa il parmater Handling nel Webmaster Center tools di Google

[Uno]

Ultimamente GOOGLE ci viene incontro con una serie di strumenti per superare questo annoso problema dei SID.

Se lo risolvi alla radice con la programmazione è meglio.
Altrimenti leggi questo post ufficiale di GOOGLE http://googlewebmastercentral.blogsp...lps-with.html:


In pratica puoi usare i SID che poi GOOGLE non legge se (meglio farli tutti):
- Ci fai una bella SITEMAP.xml con le URL pulite
- Ci metti il rel="canonical" (su ogni pagina) per indicare a GOOGLE quali sono le URL ufficiali
- Usa il parmater Handling nel Webmaster Center tools di Google

Si, si, conoscevo quelle indicazioni di Google (anche se hai sbagliato il link), ma il problema non è appunto se usi un url tipo miosito.it/index.php?cat=primacategoria&sid=iejiwijwi223j2ind iidei
In questo caso google non ha problemi a riconoscere il sid (e non esiste solo google, mi interessa anche Yahoo, Ask e i principali) ma se uso url friendly tipo miosito.it/primacategoria/iejiwijwi223j2indiidei neanche google capisce più che quello è un sid e lo considera come una pagina.
Si può ovviare con una cosa tipo miosito.it/primacategoria/sid=iejiwijwi223j2indiidei (se non ricordo male) ma non mi fa morire come soluzione, non è universale con gli altri mdr principali e non risolve un'altro problema: gli utenti che copia-incollano i link comprensivi di sid. Dal punto di vista della sicurezza basta rigenerare il sid ogni pagina, ma non mi piace avere in giro quei link.

O costringo chi vuol loggarsi ad attivare i cookie (sempre se è possibile ovunque, su alcuni cellulari mi pare non sia possibile, ma potrei ovviare con pagine apposite con sid sull'url ed inibirle ai motori tramite robots.txt ), politica di molti siti e unica opzione in alcuni framework, o non so come fare.

[luca9898]

si ci sono i due punti : in più alla fine della URL .... l'url corretta è questa: Official Google Webmaster Central Blog: New parameter handling tool helps with duplicate content issues

Beh non è che GOOGLE (e gli altri) debbano vedere TUTTE le pagine del tuo sito no.
Non puoi usare i cookie dove possibile, e quando non possibile fornisci delle pagine che vedono gli utenti e che non vedono i motori di ricerca?

[Uno]

Sul tema può a qualcuno interessare anche Official Google Webmaster Central Blog: Dynamic URLs vs. static URLs non è connesso direttamente solo al sid ma indirettamente lo tratta.

Sto provando a testare un pò di soluzioni già esistenti e un'altra cosa mi salta agli occhi.
Il sid sull'url oltre a creare problemi nei copia incolla del registrato che non ha i cookies attivi (e quindi il sid sull'url) alla fine fine non garantisce (come logica vuole) neanche l'uso decente della sessione.
Cerco di spiegarmi: se qui in questo 3d, io inserisco un url di questo stesso forum senza sid (e se lo inserissi sarebbe il mio) perchè sono loggato con il cookie, se uno loggato senza cookie lo segue automaticamente si trova non loggato perchè non c'è il suo sid.
Certo in un mio software (con mie sessioni, quelle native non hanno problemi) potrei aggiungerlo automaticamente in tutti i link interni, ma è comunque un'altra complicazione che mi sta facendo iniziare a pensare che chi ha già scelto la via del: "se non attivi i cookie non ti logghi" non ha tutti i torti, c'è anche un pelo di sicurezza in più (non tantissima, ma un pelo).
Che senso ha dare la possibilità di loggarsi senza cookie se poi ad ogni link interno ti butta fuori? Diventa anche più problematico istruire gli utenti, invece al contrario se si usano solo i coockie appena uno prova a loggarsi senza basta far visualizzare un avviso.

Sto ancora pensando alla trasformazione di tutti i link interni in form trasparenti all'utente, sarebbe un buon modo per passare in post il sid. A qualcuno viene in mente una controindicazione (motori a parte che potrei verificare con un test)?