Jump to content

Aerendir

Members
  • Content Count

    8
  • Joined

  • Last visited

Everything posted by Aerendir

  1. Ciao a tutti, vorrei parlare di SSL e certificati e di quanto questi siano veramente importanti per un ecommerce. Comincio a dirvi subito cosa ho capito leggendo un po' di materiale in rete. 1) Assunti 1.1) Funzionamento: per poter far funzionare un certificato SSL è necessario che questo sia "scaricato/nstallato" nel browser dell'utente 1.2) Per avere un certificato ci si rivolge ad una certification authority 1.3) La sicurezza del certificato è indipendente dalla certification authority poichè ciò che influisce è il tipo di crittografia utilizzato ed il suo livello di cifratura (es 128 bit) 1.4) Per utilizzare un certificato SSL si deve avere un IP dedicato, altrimenti si condivide il certificato con tutti i siti con i quali condividiamo l'IP cui il certificato si riferisce Queste affermazioni sono vere? C'è bisogno di qualche correzione? Continuo... 2) Il prezzo di un certificato varia essenzialmente in base a tre fattori: 2.1) La certification authority che ha emesso il certificato 2.2) Il tipo di cifratura utilizzato 2.3) Se il certificato è di tipo Wildcard (cioè valido per dominio di 3° livello come *.dominio.tld) Rispetto alla 2.1: più la certification authority è diffusa, più probabilità ci sono che il browser dell'utente sia "compatible" e che quindi abbia installato il certificato. Questo diminuisce le probabilità che l'utente riceva un messaggio che potrebbe apparire allarmante. Più la certification authority è diffusa maggiore sarà il prezzo Rispetto alla 2.2: serve almeno un livello pari a 128bit Rispetto alla 2.3: con i certificati wildcard si ha di fatto un unico certificato condiviso da tutti siti che fanno riferimento al dominio principale. Queste considerazioni sono vere? C'è qualche imprecisione? Potreste aggiungere qualcosa? Di fatto il certificato SSL mi serve per garantire la sicurezza delle transazioni con carta di credito. Se mi appoggio ad un gateway esterno (tipo PayPal o GestPay) non ho più bisogno di un certificato SSL perchè di tutto sto casino si occupa il gestore del gateway o mi sbaglio? Spero di essere stato chiaro ma soprattutto spero che qualcuno possa chirirmi gli eventuali errori o imprecisioni perchè a ben vedere è molto più complicato che scegliere il piano di hosting (argomento anch'esso di per se non proprio chiarissimo a chi ci si avvicina per la prima volta!). Grazie mille a tutti, ciao!
  2. Aerendir

    Consiglio e-commerce

    Aspettate un attimo, Magento è commerciale! Non è un progetto Open Source nel senso di Free Software. Tanto è vero che la licenza non è nemmeno la GPL. Il modello di business è semplicemente freemium: ti danno la versione free e te ne fanno vedere il codice. Se vuoi altre funzioni, quelle molto più avanzate, paghi e ti compri la versione commerciale (che costa molto, migliaia di euro, non centinaia!). Per la documentazione non so dirvi... in giro certamente non ce n'è molta. Poi, ovvio dipende da ciò che si vuol fare. htnl.it, comunque, ha pubblicato in questi giorni una guida: Guida Magento | Guide CMS | Cms.HTML.it Per ciò che riguarda la programmazione o il design, invece, io ho comprato due libri su PackPublishing (e ho comprato anche un paio di guide per iniziare). Altro problema di Magento, se proprio la vogliamo dire tutta, è che le estensioni costano moltissimo. Io credo, comunque, che sia una situazione destinata a cambiare: la legge del mercato non perdona e più saranno gli sviluppatori più si inizierà a vedere un abbassamento dei prezzi. Quindi, ricapitolando: PrestaShop, open source/free software puro, buono per esigenze medie. Magento, costoso ma molto molto stabile, per esigenze medio grandi-grandissime.
  3. Aerendir

    Consiglio e-commerce

    Per il primo progetto, quello con 200 articoli, va bene anche PrestaShop. Per il secondo il mio consiglio è di usare assolutamente Magento. Ti dico la mia opinione. OsCommerce ha fatto il suo corso: è stato un ottimo software di e-commerce ma ormai è superato, anche alla luce delle evoluzioni che ci sono state. È scritto ancora con vecchi criteri ed anche io ho sentito voci che dicevano che lo sviluppo è fermo (tanto è vero che ci hanno fatto un fork, TomatoCart). Joomla e VirtueMart li ho usati: VirtueMart è macchinoso, senza aggiungere che molte funzioni essenziali non ci sono (vedi la pessima gestione degli sconti). PrestaShop mi pare un ottimo compromesso tra facilità di utilizzo e funzioni. Magento, invece, ritengo sia il miglior software di e-commerce attualmente in circolazione, sotto tutti i punti di vista. Qualcuno dice che è complicato: io sono convinto che abbia una più alta curva di apprendimento per il semplice fatto che offre funzioni che il 90% delle person che inizia a fare e-commerce non sa ancora che gli serviranno ma quando se ne accorgerà lì le troverà. Per la velocità, sia lato backend che lato frontend basta qualche piccolo accorgimento e la differenza nn si nota. Però tutto è douto al fatto che è completo e sviluppato in maniera più che ottima.
  4. Hai visto che alla fine abbiamo trovato un punto d'incontro! Anche io sono d'accordo con questa affermazione. Buona serata anche a te :D
  5. Ok, grazie, sei stato chiaaarissimo. Ah, ho capito :approved:
  6. Veramente no, non lo sapevo:asd:. Non studio Ingegneria, studio Giurisprudenza. Ma lo terrò presente, grazie:zizi:. Sono d'accordo con te, evitiamo l'OT che si sarebbe dovuto evitare dall'inizio. Magari se mi rispondi anche sul SSL mi fai cosa gradita che in tutta sta storia ancora non ci ho capito niente!!!
  7. In questo caso, ma in questo caso particolare (non nell'ecommerce di cui stiamo parlando) hai ragione, la sicurezza e l'anonimità del dato è assicurata e quindi non c'è bisogno di criptare nulla (ma io lo farei comunque perchè i dati del paziente possono comunque portare ad identificarlo). Qua te lo dice chiaramente ma solo per dati sanitari o che riguardino la vita sessuale ecc. ecc.. Ti ho esposto, invece, ancora più chiaramente e analiticamente, il resto delle norme dello stesso codice che ti impongono sia di cifrare il db, sia di comunicare i dati in maniera cifrata (con SSL) negli altri casi che non possono essere ricondotti al trattamento di dati sanitari. Ah aha, si, lo so che non è la stessa cosa :D E so anche che nessuno lo vieta, lo impongono proprio! E' questo il punto: il fatto che non sia scritto chiaro e tondo non vuol dire che l'obbligo non ci sia! Ci si arriva per via interpretativa. Sia chiaro, non è mia intenzione essere polemico, arrogante o presuntuoso ma ti ripeto che è così, ci sono CLAUSOLE GENERALI (http://it.wikipedia.org/wiki/Clausola_generale e si fa proprio riferimento alla "correttezza") e PRINCIPI GIURIDICI che possono essere evinti dalla lettura dell'intero codice della privacy (ed è così che i codici si leggono, non si legge il singolo articolo, MAI!), è l'interpretazione cosiddetta sistematica (Interpretazione giuridica - Wikipedia). Il mio non era un attacco a te direttamente ma solo un voler mettermi a disposizione della community che a quanto pare a riguardo fa un bel po' di confusione e trova difficoltà. Non so se l'hai studiato, con chi o come e nemmeno mi interessa. Il consiglio che ti posso dare è che se veramente pensi che sia così perchè te l'hanno detto fose l'avvocato da cui sei andato non si è spiegato molto bene o non ha capito bene quale fosse il tuo problema. Poi rimane che è sempre una questione di interpretazione e soprattutto che le regole sono talmente tante e prevedono così tante sfaccettature e varianti che cambiano da caso a caso: basta nulla per modificare interamente la disciplina da applicare. Se ti fidi di quanto ti dico sono contento, se non ti fidi non posso farci niente oltre che dispiacermene, volevo solo essere utile. Tornando al mio benedetto SSL esiste una risorsa in rete che mi spieghi quali sono i tipi di certificati (ora ho scoperto che esitono anche quelli Extended Validation per i quali l'authority pima di emetterli effettua controlli sull'identità di qualcuno ma non ho capito se del server o se del proprietario del server), a che servono, ecc. ? NOn mi interessa la prate tecnica (tipo il funzionamento dei protocolli di cifratura e trasmissione dei dati) ma mi interessa capire cme funzionano a grandi linee e quali sono i vantaggi o gli svantaggi derivanti dall'usarne uno piuttosto che un altro.
  8. Alla faccia! Ho sollevato un polverone!!! :D Facciamo così, anche se siamo OT io provo a rispindervi (studio Giurisprudenza e qualche indicazione ve la posso dare); voi, però mi finite di spiegare come funziona sto benedetto SSL ;) Ora non ricordo le risposte precise di tutti quanti però vi spiego come funziona. Per prima cosa mi preme dirvi che non basta leggere solo un articolo per capire qual è la discplina da applicare. Questo vuol dire che il solo art. 24 non basta. Ma andiamo con ordine. Nel codice ci sono molti articoli che possono essere applicati al commercio elettronico e che contribuiscono a delinearne parte della disciplina. Per prima cosa distinguiamo tra dati personali e dati sensibili. Per dato personale si intende anche l'identificativo che permette di risalire all'identità della persona. Lo stabilisce l'art. 4 lettera b) quando dispone Per capirci quello che nel DB è memorizzato nel campo ID. Quindi questo non è vero. Anche l'id di collegamento tra scheda e cliente è un dato personale proprio perchè permette di risalire all'identità della persona. I dati personali DEVONO ESSERE PROTETTI! All'art. 11, rubricato "modalità del trattamento e requisiti dei dati", il comma primo dispone che "Secondo correttezza" è una clausola generale. E secondo correttezza io devo conservare i dati personali in una forma che ne impedisca il furto o comunque l'uso illeggittimo e la diretta conseguenza è che anche la trasmissione deve avvenire con modalità tali da evitare il verificarsi di queste situazioni. Già solo questo basterebbe a configurare l'obbligo, in capo ai commercianti titolari di ecommerce, di utilizzo del SSL o di altra tecnologia idonea a garantire la sicurezza dei dati trattati. Ma c'è di più. L'articolo 34 dispone, infatti, che Le lettere a) e b) impone l'uso di autenticazione e di procedure di autenticazione Ma qui si potrebbe dibattere sul se questa dizione ricomprenda solo l'uso di coppie di username/password o se ricomprenda anche l'uso di cifratura. Spetta alla dottrina chiarire il concetto e alla giurisprudenza "farlo diventare legge". La cifratura è comunque richiamata nella lettera e) allorquando si parla di "protezione degli strumenti elettronici e dei dati rispetto a trattamenti illeciti di dati, ad accessi non consentiti e a determinati programmi informatici". Tutto questo lo si ottiene proprio con la cifratura. Quindi c'è l'obbligo di utilizzarla.La cifratura è però espressamente prevista per alcuni dati sensibili. Si richiama, comunque, l'allegato B (che io onestamente non ho letto). All'art. 13 si parla di informativa. In questa il predisponente deve specificare se la comunicazione dei dati è obbligatori o meno, a chi verranno comunicati i dati e per quali finalità, ecc. Quindi nei social network se si leggono le privacy policy si dovrebbe trovare proprio questa informativa e lo stesso vale per gli altri siti ai quali comunichiamo dati. Se nella policy c'è scritto che altri utenti potranno prendere visione dei dati e io accetto non è un problema di codice ma di attenzione delle persone: se accetto nessun codice potrà mai fare niente. Art. 24 La parte importante ai fini della fatturazione non è tanto la lettera a) quanto la lettera b): "Eseguire obblighi derivanti da contratto".Il clinete non potrà mai richiedere la cancellazione dei dati in questo caso poichè essi servono ai fini dell'adempimento fiscale. Al massimo potrà chiedere la cancellazione dell'account ma la fattura dovrà comunque continuare a riportare i dati personali identificativi del cliente. Quindi la fattura non si strappa ;) Alla luce di quanto vi ho sommariamente scritto la regola generale è che la cifratura va utilizzata ogni volta che è necessario il trattamento di dati anche solo personali perchè anche se non espressamente richiamata dalle norme ci sono clausole generali e principi normativi che vi fanno riferimento. Ovviamente questo vale sia nel frontend, che nel backend. Il problema fondamentale, comunque, non è tanto se esite una normativa o non esiste ma se viene fatta rispettare o non viene fatta rispettare. Esiste il Garante per la Privacy che dovrebbe occuparsi di questo. Se ritenete di essere stati lesi nel vostro diritto alla privacy o andate da un avvocato, o lo segnalate al garante stesso. Comunque è una cosa lunga e credo nemmeno semplice e forse porta anche spese. Avete capito perchè nessuno rispetta la normativa? ;) Detto questo, torniamo al SSL?
×