View Full Version : Sicurezza nella creazione sito e-commerce
Ciao a tutti, avrei bisogno di un consiglio visto che è la prima volta che realizzo in php un sito di e-commerce senza seguire una guida specifica e soprattutto senza usare cms.
Per la realizzazzione del carrello ho usato le sessioni.
Ora io non so se in termini di sicurezza ho omesso qualcosa e vorrei a tal proposito capire se ci sono da fare dei cambiamenti per evitare sorprese. L'unica cosa che ho fatto è un controllo sulla pagina che mi invia l'ordine nel database, in pratica se nella stessa sessione mi è già arrivato l'ordine nel database ma il cliente deve ancora pagare con la carta , non permetto di aggiornare la pagina (perchè il carrello a questo punto sarebbe vuoto) ,e nè di farne inviare un altro da un'altra finestra del browser, costringo il cliente a finire tutto il procedimento nella stessa finestra e se vuole creare un nuovo carrello, deve prima concludere quello precedente o almeno azzerare il carrello attuale.
Non ho usato nessun sistema di crittografia e non so neache se sia il caso, perchè dovrebbe essere nel mio caso Paypal a usare sistemi di sicurezza penso.
Il sito sembra funziona bene, ma come faccio a sapere se ho realizzato un sistema sicuro prima ancora che si passi il totale della somma del carrello a paypal?
Se qualcuno vuol vedere online la bozza del progetto posso anche fornire l'url.
Grazie.
Ciao a tutti, avrei bisogno di un consiglio visto che è la prima volta che realizzo in php un sito di e-commerce senza seguire una guida specifica e soprattutto senza usare cms.
Per la realizzazzione del carrello ho usato le sessioni.
Ora io non so se in termini di sicurezza ho omesso qualcosa e vorrei a tal proposito capire se ci sono da fare dei cambiamenti per evitare sorprese. L'unica cosa che ho fatto è un controllo sulla pagina che mi invia l'ordine nel database, in pratica se nella stessa sessione mi è già arrivato l'ordine nel database ma il cliente deve ancora pagare con la carta , non permetto di aggiornare la pagina (perchè il carrello a questo punto sarebbe vuoto) ,e nè di farne inviare un altro da un'altra finestra del browser, costringo il cliente a finire tutto il procedimento nella stessa finestra e se vuole creare un nuovo carrello, deve prima concludere quello precedente o almeno azzerare il carrello attuale.
Non ho usato nessun sistema di crittografia e non so neache se sia il caso, perchè dovrebbe essere nel mio caso Paypal a usare sistemi di sicurezza penso.
Il sito sembra funziona bene, ma come faccio a sapere se ho realizzato un sistema sicuro prima ancora che si passi il totale della somma del carrello a paypal?
Se qualcuno vuol vedere online la bozza del progetto posso anche fornire l'url.
Grazie.
Allora premesso il fatto che QUALSIASI sistema online che PERMETTA lo scambio di DATI SENSIBILI tra CLIENT e SERVER (anche il più semplice modulo contatti) sarebbe l'ideale realizzarlo attraverso una connessione crittografata SSL.
Ma questo è un mio personalissimo punto di vista che puoi prenderlo come spunto tu per aumentare il livello di sicurezza; rispondendo alla tua domanda realizzerei TUTTO il carrello e il CHECKOUT sotto crittografia SSL (https).
Per quanto riguarda le sessioni nel carrello è l'unica soluzione fruibile sinceramente, che ti occupa poco tempo e sono abbastanza affidabili; creare delle tabelle temporanee sarebbe troppo esoso in termini di memoria (usi MySQL sicuramente...) e quindi le lascerei da parte.
Spiega bene il procedimento che hai adoperato nella realizzazione del carrello, dall'inserimento del prodotto al checkout. Quando e come controlli la disponibilità del prodotto?
Per PayPAL puoi andare tranquillo poi. :)
In pratica ho creato un' array sessione dove ogni volta che un utente clicca sul pulsante "Aggiungi al carrello", tramite il metodo post incremento l'array sessione e la somma da pagare. Il totale lo inserisco poi in un'altra sessione. Quando l'utente ha terminato lo shopping, entra nella pagina carrello, complila un form per i suoi dati e clicca sul pulsante acquista. Sempre con il metodo post mi arriva l'ordine nel database e a questo punto svuoto la sessione carrello, tuttavia se il pagamento è con carta di credito nella pagina successiva appare il pulsante di paypal. I valori passati a quest' ultimo sono i due array sessione, e cioè gli articoli e l' importo totale. Quando Paypal mi avvisa che il pagamento è avvenuto, aggiorno un campo nel database che mi serve per identificare un ordine ormai pagato.
Per quanto riguarda la disponibilità del prodotto, non ho per ora l'esigenza di prenderlo in considerazione.
Io non ho usato nessun https per creare il carrello, e sinceramente non l' ho mai fatto e non so come fare.
E' rischioso in questa maniera? Cosa potrebbe succedere?
In pratica ho creato un' array sessione dove ogni volta che un utente clicca sul pulsante "Aggiungi al carrello", tramite il metodo post incremento l'array sessione e la somma da pagare. Il totale lo inserisco poi in un'altra sessione. Quando l'utente ha terminato lo shopping, entra nella pagina carrello, complila un form per i suoi dati e clicca sul pulsante acquista. Sempre con il metodo post mi arriva l'ordine nel database e a questo punto svuoto la sessione carrello, tuttavia se il pagamento è con carta di credito nella pagina successiva appare il pulsante di paypal. I valori passati a quest' ultimo sono i due array sessione, e cioè gli articoli e l' importo totale. Quando Paypal mi avvisa che il pagamento è avvenuto, aggiorno un campo nel database che mi serve per identificare un ordine ormai pagato.
Per quanto riguarda la disponibilità del prodotto, non ho per ora l'esigenza di prenderlo in considerazione.
Io non ho usato nessun https per creare il carrello, e sinceramente non l' ho mai fatto e non so come fare.
E' rischioso in questa maniera? Cosa potrebbe succedere?
Beh se hai usato un sistema saggio e corretto per filtrare tutti i dati in transazione su POST e SESSION sei a posto così a rigor di logica è un procedimento corretto.
Quando andrai ad analizzare la disponibilità dei prodotti (cosa che dovresti tenere in considerazione fin da subito, se due utenti acquistano contemporaneamente, cosa succede?) dovrai lavorarci con molta attenzione.
Per HTTPS basta che attivi un certificato SSL su Apache; a questo punto per 20 dollari conviene comprarne uno certificato... (per modo di dire... ;))
Ma poi quale sarebbe il rischio? Infondo il pagamento avviene su paypal in https. In dati passati a pay pal con il metodo post sono gli articoli, la somma totale e i dati del cliente. Possono essere manipolati in qualche modo prima di arrivare a paypal?
Ma poi quale sarebbe il rischio? Infondo il pagamento avviene su paypal in https. In dati passati a pay pal con il metodo post sono gli articoli, la somma totale e i dati del cliente. Possono essere manipolati in qualche modo prima di arrivare a paypal?
Ogni dato può essere manipolato in una richiesta HTTP.
Il problema non è la loro manipolazione, ma peggio, una perdita dei dati sensibili... ovvero violazione dei dati personali da parte di qualche utente malintenzionato.
Poi oddio, io ti sto allarmando per niente, non ti accadrà mai, ma prevenire è meglio che curare... e poi hai chiesto tu tecniche aggiuntive per 'mettere in maggiore sicurezza il tutto'. :)
ah si certo, e ti ringrazio. Mi hai dato 2 input. Il primo riguarda la possibilità che due persone ordino contemporaneamente lo stesso prodottoe quindi sarebbe un problema, e l'altro la possibilità di inserire un certificato ssl se non ho capito male.
Per il primo problema che mi consigli? Si mette in attesa una richiesta sql?
Poi mi piacerebbe capire come implementare questo sistema di sicurezza ssl, sai indicarmi una guida?
pabloski
30-06-2010, 12:54
paypal offre gli script necessari se non sbaglio e quelli sfruttano ssl
Paypal si, ma durante la gestione del carrello e l'invio dei dati del cliente sul mio database, non c'è paypal, io alla fine passo a paypal la somma totale e alcuni dati dell' utente,(come il nome , il cognome e il suo indirizzo email). La mia preoccupazione quindi è prima che si apra la pagina di paypal, non vorrei che i dati inviati via post o le sessioni vengano fossero manipolate in qualche modo.
https lo dovresti usare anche tu nelle pagine di checkout...
Le sessioni non te le può toccare nessuno, sono sul server.
ah si certo, e ti ringrazio. Mi hai dato 2 input. Il primo riguarda la possibilità che due persone ordino contemporaneamente lo stesso prodottoe quindi sarebbe un problema, e l'altro la possibilità di inserire un certificato ssl se non ho capito male.
Per il primo problema che mi consigli? Si mette in attesa una richiesta sql?
Poi mi piacerebbe capire come implementare questo sistema di sicurezza ssl, sai indicarmi una guida?
Beh per il secondo niente di meglio SSLEngine su Apache2.
Basta che googli, trovi il mondo. Ricordati che i certificati ssl puoi generarli tu stesso con ssl-cert sul server, peccato che non essendo 'trust' quindi riconosciuti alcuni Browser (Firefox e Safari) 'avvisano' l'utente e quindi è sgradevole. I certificati SSL 'certificati e riconosciuti' (perdona il gioco di parole) costano dai 20 $ ai 1000 $ annuali; dipende sempre l'uso che devi farne.
Per il primo punto... o fai un lock sulle tabelle (il che ti obbliga di avere i permessi sul database, con l'utente, cosa non ideale) oppure ti crei una tabella temporanea dove metti ID prodotto, quantità virtuale. Punto. Quando la quantità virtuale (e la devi controllare ad ogni pagina dal checkout al pre-pagamento) è superiore alla disponibilità, procedi, altrimenti no.
Successivamente a pagamento completato aggiorni la quantità reale.
PS. Cionci l'SSL andrebbe usato ovunque, anche sul normalissimo modulo contatti :)
nuovoUtente86
30-06-2010, 14:13
Cionci l'SSL andrebbe usato ovunque, anche sul normalissimo modulo contatti
non vedo l' utilità di appesantire la computazione e l' overhead di rete, in sezioni non necessarie ovvero dove non passano dati sensibili.
non vedo l' utilità di appesantire la computazione e l' overhead di rete, in sezioni non necessarie ovvero dove non passano dati sensibili.
Un modulo contatti non contiene dati sensibili?
Nome, Cognome, E-mail, TELEFONO, P.IVA e CF, sesso, indirizzo o altri dati non sono ritenuti dati sensibili o personai?
Forse bisogna rivedere il 'rango' dei dati riconosciuti come 'sensibili' e 'personali'.
Per me e per la legge Italiana lo sono.
Per te non lo so.
Che poi l'SSL appesantisca le connessioni, le renda più lente, ecc. è un altro conto; preferisco metterci 2 secondi in più a caricare una pagina che rischiare che i miei dati vengano passati in chiaro. Ma IMHO, questione di gusti e priorità.
EDIT: lascerei però questo discorso a chi è ferrato in materia di Privacy.
SSL tutta la vita. ;)
!k-0t1c!
30-06-2010, 15:11
A parte l'SSL che ti è già stato consigliato ti raccomando un modo per verificare che la sessione non sia manipolata. Nella fattispecie un modo molto sicuro di fare tutto sarebbe salvare nella sessione esclusivamente dei codici identificativi di prodotto. Al momento del checkout avresti così l'occasione non solo di verificare la disponibilità (pensa a due clienti che scelgono lo stesso prodotto, con disponibilità 1: solo il primo a fare il checkout dovrebbe avere l'occasione di arrivare al pagamento), ma anche di fare la somma effettiva dei prezzi senza temere manipolazioni da parte dell'utente; il tutto, naturalmente, essendo eseguito sul server, non comporterebbe particolari rischi.
In alternativa potresti sempre usare una forma di hashing (HMAC?) dei dati di sessione e verificare l'hash alla fine della procedura, anche se la soluzione è certamente meno sicura ed efficace.
Userei poi, fossi in te, uno strettissimo controllo su classici quali SQL injection e XSS, poiché un'SQL injection - ad esempio - consentirebbe ad un cliente malintenzionato di garantirsi uno sconto, mentre un'XSS potrebbe compromettere la sicurezza dei dati personali di un cliente legittimo e portare ad acquisti non autorizzati con tutte le conseguenze del caso.
nuovoUtente86
30-06-2010, 15:13
Le sessioni non te le può toccare nessuno, sono sul server.
teoricamente esiste la vulnerabilità dovuta al sessionid sniffing, ma neanche ciò giustifica un uso spasmodico di https.
Occorre invece garantire, lato server, che non possano verificarsi attacchi di tipo session riding
nuovoUtente86
30-06-2010, 15:21
Cionci l'SSL andrebbe usato ovunque
senza fare polemica, in italiano la parola ovunque ha un significato preciso.
Un modulo contatti non contiene dati sensibili?
Nome, Cognome, E-mail, TELEFONO, P.IVA e CF, sesso, indirizzo o altri dati non sono ritenuti dati sensibili o personai?
Forse bisogna rivedere il 'rango' dei dati riconosciuti come 'sensibili' e 'personali'.
Per me e per la legge Italiana lo sono.
Per te non lo so.
Che poi l'SSL appesantisca le connessioni, le renda più lente, ecc. è un altro conto; preferisco metterci 2 secondi in più a caricare una pagina che rischiare che i miei dati vengano passati in chiaro. Ma IMHO, questione di gusti e priorità.
Solitamente i moduli di contatto non hanno tale livello di dettaglio, implementato nei moduli di registrazione, che di norma viaggiano, questi si, su SSL
senza fare polemica, in italiano la parola ovunque ha un significato preciso.
Solitamente i moduli di contatto non hanno tale livello di dettaglio, implementato nei moduli di registrazione, che di norma viaggiano, questi si, su SSL
Probabilmente non hai letto il topic sopra: la parole ovunque in Italiano, ha un significato ben preciso come sostieni tu, ma se ti fossi soffermato un solo secondo sul mio intervento avresti letto e capito che il mio ovunque si riferiva 'ovunque vi sia una comunicazione client - server in presenza di dati sensibili/personali' :mbe:.
Per i moduli di contatto, dipende sempre dai casi.
Giusta cosa sulle sessioni.
nuovoUtente86
30-06-2010, 15:39
Coerentemente sarebbe opportuno far viaggire il sessionID (e di conseguenza tutti i messaggi HTTP) su un canale criptato, in quanto intercettando si ha pieno accesso alla sessione, con le conseguenze del caso, ma per motivi di performance nessuna web-application (anche delle note multinazionali dell' e-commerce) viaggia completamente su TLS
teoricamente esiste la vulnerabilità dovuta al sessionid sniffing, ma neanche ciò giustifica un uso spasmodico di https.
Occorre invece garantire, lato server, che non possano verificarsi attacchi di tipo session riding
Io ho detto ben altra cosa. I dati memorizzati sulla sessione sono conservati sul server, quindi è chiaro che di quelli non deve preoccuparsi.
La gestione del sessionID è ben altra cosa. Il controllo del referer è d'obbligo...
Prima di tutto bisognerebbe usare il metodo GET il meno possibile e nella chiusura delle transazioni bisognerebbe memorizzare il referer che ci si aspetta o una onetime password all'interno della sessione, per poi verificarla quando arriva la richiesta effettiva che chiude la transazione.
nuovoUtente86
30-06-2010, 15:54
Io ho detto ben altra cosa. I dati memorizzati sulla sessione sono conservati sul server, quindi è chiaro che di quelli non deve preoccuparsi.
La gestione del sessionID è ben altra cosa. Il controllo del referer è d'obbligo...
Prima di tutto bisognerebbe usare il metodo GET il meno possibile e nella chiusura delle transazioni bisognerebbe memorizzare il referer che ci si aspetta o una onetime password all'interno della sessione, per poi verificarla quando arriva la richiesta effettiva che chiude la transazione.
Ho quotato il tuo messaggio solo per agganciarmi al discorso sessioni, non per l' integrità dei dati conservati sul server bensi per l' accessibilità alla stessa. Sicuramente l' utilizzo di un token univoco e non predicibile è una delle tecniche più efficaci. Anche il referer offre ampie garanzia, anche se esiste una remota possibiltà di spoofing.
Io non passo niente con il metodo GET ma solo con il metodo POST. Comunque mi pare di capire che le sessioni possono comunque essere intercettate e quindi mi conviene usare un certificato ssl almeno dalla pagina dove il cliente incomincia a compilare il form dopo aver finito lo shopping. Giusto?
Purtroppo non ho capito proprio tutto il vostro discorso, ad esempio non so cosa sia il refer, ma se serve per identificare l'ordine, io ho fatto in modo che quando l'utente ha finito di compilare il form, si inserisce l'ordine nel database e mi viene inviata una email con un codice univoco per identificare il cliente e l'ordine. Dopodichè le sessioni vengono distrutte.
nuovoUtente86
30-06-2010, 17:52
Senza entrare troppo nel tecnico, come saprai HTTp è un protocollo stateless per cui impone il mantenimento dello stato conversazionale in maniera programmatica. Solitamente tale stato viene mantenuto attraverso dei piccoli file rimbalzati tra client e server, appunto i cookie. Una volta in tali file venivano memorizzati dati utili allo stato applicativo, oggi, per questioni di sicurezza si tende a mantenere tali dati sul server ed utilizzare i cookie come riferimento alla sessione stessa.
Tale meccanismo è utilizzato per mantenere anche lo stato di autenticazione di ogni utente, e se è vero che la fase di login è gestita su trasporto sicuro, lo stesso non è per le operazioni successive (o almeno non per tutte). Va da se che chiunque riesca a sniffare un sessionID (puooi farlo tu stesso attraverso wireshark a titolo di curiosità) oppure riesca ad indurre un utente ad utilizzare una sessione nota, può avere libero accesso, ad esempio alla gestione dell' account o degli ordini.
Ora questa è pura teoria, nella pratica vanno realisticamente ponderate le superfici di attacco, come le reti wireless ma ormai anche gli utenti medi sono ben attenti agli aspetti crittografici (e di solito si da accesso a persone fidate) mentre gli hotspot ben fatti implementano tecniche di virtual switching (al minimo anche il wpa lo fa), e se cosi non fosse in ogni caso si sarebbe esposti a rischi anche su SSL, che è vulnerabile ad attacchi MITM.
Questo per dire che, un codice server-side ben programmato offre un ottimo compromesso di sicurezza anche senza ricorrere in maniera ossessiva alla sicurezza di canale.
Non possono essere intercettati i dati che sono in sessione, può venire intercettato il SessionId, che è quell'identificativo che viaggia fra client e server sotto forma, solitamente, di cookie. Chiaramente se ho il SessionId posso anche recuperare i dati della sessione "travestendomi" da client.
Un modo per proteggersi dal session spoofing è quello di memorizzare l'indirizzo IP del client nella sessione. Se l'indirizzo non corrisponde non accetto la richiesta. Questa cosa è aggirabile, ma solitamente solo in un verso: cioè si possono inviare richieste spoofate (falsificando il proprio indirizzo IP), ma non si possono ricevere le risposte a tali richieste (perché vanno a finire all'indirizzo IP originale), ovviamente sempre che l'attaccante non possa leggere tutto il mio traffico. E' quindi chiaro che se una transazione si svolge in tre fasi:
1 - client request
2 - server reply
3 - client confirmation
E nel server reply includi una onetime password, diventa veramente difficile sfruttare l'ip spoofing. A meno di flaw nella generazione della onetime password.
Una onetime password è ad esempio un stringa generata a partire da:
- data e ora attuale
- username e password
- numero di richieste totali di onetime password (un semplice contatore su un database è sufficiente)
Ti crei una stringa composta da tutte queste informazioni ed applichi un hash come SHA1.
Spedisci questo SHA1 al client in un campo hidden del form di conferma della transazione e lo salvi nella sessione. Quindi il client te lo rimanda con la form e tu lo verifichi prima di chiudere la transazione.
Il referer è un campo dell'intestazione HTTP che arriva insieme alla richiesta. Indica l'url della pagina da cui è partita la richiesta corrente.
In php: $_SERVER['HTTP_REFERER']
che è vulnerabile ad attacchi MITM.
Questo per dire che, un codice server-side ben programmato offre un ottimo compromesso di sicurezza anche senza ricorrere in maniera ossessiva alla sicurezza di canale.
Per completezza: MITM = Man In The Middle, cioè l'attaccante si trova in un posizione del percorso che fanno i dati sulla rete che gli permette di leggere/monitorare e/o modificare i dati che il server ed il client si scambiano.
In ogni caso concordo anche io sull'ultima riflessione ;)
nuovoUtente86
30-06-2010, 17:58
La verifica dell' Ip, però non è una tecnica realmente realizzabile per 2 questioni principali:
- la maggior parte delle connessioni consumer hanno ip dinamico, che potrebbe cambiare in maniera del tutto legittima.
- ormai molti client condividono gli ip pubblici, ed è proprio sui segmenti privati che si è più esposti al furto del sessionID, rendendo di fatto nullo tale controllo.
La verifica dell' Ip, però non è una tecnica realmente realizzabile per 2 questioni principali:
- la maggior parte delle connessioni consumer hanno ip dinamico, che potrebbe cambiare in maniera del tutto legittima.
- ormai molti client condividono gli ip pubblici, ed è proprio sui segmenti privati che si è più esposti al furto del sessionID, rendendo di fatto nullo tale controllo.
E' però un livello ulteriore di protezione. Non è certa, ma è sicuramente utile.
Se l'IP cambia legittimamente, si fa decadere comunque la sessione. Mi sembra anche giusto...
Ragazzi complimenti per la conoscenza in materia, ma vorrei risolverla in un modo semplice perchè in sicurezza sono poco esperto e ho difficoltà a seguirvi. Riassumendo, per risolvere tutto ed essere sicuri che i dati non vengano intercettati posso inserire un certificato ssl almeno dalla pagina dove il cliente incomicia a compilare il form?
nuovoUtente86
30-06-2010, 18:14
Non possono essere intercettati i dati che sono in sessione, può venire intercettato il SessionId, che è quell'identificativo che viaggia fra client e server sotto forma, solitamente, di cookie. Chiaramente se ho il SessionId posso anche recuperare i dati della sessione "travestendomi" da client.
Un modo per proteggersi dal session spoofing è quello di memorizzare l'indirizzo IP del client nella sessione. Se l'indirizzo non corrisponde non accetto la richiesta. Questa cosa è aggirabile, ma solitamente solo in un verso: cioè si possono inviare richieste spoofate (falsificando il proprio indirizzo IP), ma non si possono ricevere le risposte a tali richieste (perché vanno a finire all'indirizzo IP originale), ovviamente sempre che l'attaccante non possa leggere tutto il mio traffico. E' quindi chiaro che se una transazione si svolge in tre fasi:
1 - client request
2 - server reply
3 - client confirmation
E nel server reply includi una onetime password, diventa veramente difficile sfruttare l'ip spoofing. A meno di flaw nella generazione della onetime password.
Una onetime password è ad esempio un stringa generata a partire da:
- data e ora attuale
- username e password
- numero di richieste totali di onetime password (un semplice contatore su un database è sufficiente)
Ti crei una stringa composta da tutte queste informazioni ed applichi un hash come SHA1.
Spedisci questo SHA1 al client in un campo hidden del form di conferma della transazione e lo salvi nella sessione. Quindi il client te lo rimanda con la form e tu lo verifichi prima di chiudere la transazione.
Il referer è un campo dell'intestazione HTTP che arriva insieme alla richiesta. Indica l'url della pagina da cui è partita la richiesta corrente.
In php: $_SERVER['HTTP_REFERER']
Giusto per aggiungere una chicca sul discorso ip spoofing, va detto che la maggior tecnica utilizzata è il source routing, anche se oggi i provider e i sistemi operativi non lo supportano (o almeno dovrebbero, ma su Windows è attivo di default). Questo per dire che un altro aspetto fondamentale, è l' amministrazione del server.
Riassumendo, per risolvere tutto ed essere sicuri che i dati non vengano intercettati
Non potrai mai essere sicuro ;)
Sicuramente una sessione SSL al momento del checkout è buona cosa, fino al completamento della transazione.
Tre tecniche piuttosto semplici da usare te le ho date:
- salvare l'IP nella sessione e verificarlo ad ogni richiesta
- controllare il referer (se una richiesta arriva ad una pagina di checkout ad esempio può avere come referer solo determinate pagine del tuo sito)
- onetime password nei form (ad esempio quando generi il form del carrello puoi inserire la onetime password per fare il checkout)
Ok grazie, valuterò i casi, almeno ho capito cosa si può fare.
nuovoUtente86
30-06-2010, 19:40
E' però un livello ulteriore di protezione. Non è certa, ma è sicuramente utile.
Se l'IP cambia legittimamente, si fa decadere comunque la sessione. Mi sembra anche giusto...
Come si diceva in qualche post precedente, dipende anche dal gusto personale dello sviluppatore (e per fortuna che il mondo è vario), però se colossi come Ebay e Paypal, che su questo vivono e straguadagnano, non lo fanno qualche motivo ci sarà. Personalmente troverei fastidiosa, lato utente, una disconnessione improvvisa perchè il provider cambia ip, ma magari per altri è una buona soluzione.
Come si diceva in qualche post precedente, dipende anche dal gusto personale dello sviluppatore (e per fortuna che il mondo è vario), però se colossi come Ebay e Paypal, che su questo vivono e straguadagnano, non lo fanno qualche motivo ci sarà. Personalmente troverei fastidiosa, lato utente, una disconnessione improvvisa perchè il provider cambia ip, ma magari per altri è una buona soluzione.
Quoto. In ufficio abbiamo una doppia linea con doppio IP in uscita, di conseguenza, spesso, mi vedo saltare la connessione (Internet Banking, ecc) e la cosa, anche se sicura, è alquanto fastidiosa.
nuovoUtente86
30-06-2010, 20:47
Quoto. In ufficio abbiamo una doppia linea con doppio IP in uscita, di conseguenza, spesso, mi vedo saltare la connessione (Internet Banking, ecc) e la cosa, anche se sicura, è alquanto fastidiosa.
Ora rischiamo di andare OT, ma potrebbe essere anche un problema indipendente dall' implementazione applicativa, ma ad un livello più basso ovvero di bonding o load balancing non gestito correttamente.
Ora rischiamo di andare OT, ma potrebbe essere anche un problema indipendente dall' implementazione applicativa, ma ad un livello più basso ovvero di bonding o load balancing non gestito correttamente.
Su un IB penso sia più una questione 'applicativa' che un problema da sistemisti ;)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.