Come valutare le estensioni di terze parti?

Mentre Magento fa molto "out of the box", abbiamo scoperto che ci sono inevitabilmente funzionalità e servizi necessari per i negozi client che richiedono un'estensione di terze parti.

Tuttavia, data la natura del mezzo, può essere una proposta rischiosa introdurre un codice "straniero" in un sistema così complesso che si occupa di transazioni commerciali.

Cosa cerchi quando valuti le estensioni di Magento? Quali sono le "bandiere rosse" che hai incontrato (maiali delle prestazioni, rischi per la sicurezza, cattive pratiche architettoniche)?

Ecco alcune considerazioni sulla valutazione dei moduli di terze parti:

Nozioni di base:

• Supporto della versione attuale di Magento - Supporta l'ultima versione di Magento (inclusa quella attuale per cui lo stiamo sviluppando)?

  Se un modulo non supporta l'ultima versione di Magento, sarà probabilmente difficile farlo funzionare senza dedicare tempo prezioso allo sviluppo.

• Supporto: gli sviluppatori che hanno creato il modulo supportano il prodotto?

  Uno dei segni di un modulo sano è che gli sviluppatori lo supportano attivamente. Se non lo supportano è una bandiera rossa, perché non supporteranno il prodotto se è buono?

  Inoltre, quando un modulo è supportato, di solito possiamo ottenere informazioni importanti dagli sviluppatori con una semplice e-mail (ad esempio, questo modulo utilizza jQuery o Prototype).

• Recensioni - Cosa dicono gli altri utenti? Come è stata la loro esperienza?

  Leggendo le recensioni possiamo capire meglio il quadro generale, c'è un problema di installazione? Gli sviluppatori rispondono in modo tempestivo e utile? Funziona come pubblicizzato?

• Rimborso - Ti restituiranno i tuoi soldi se non funzioneranno come previsto?

  Molte volte vogliamo provare il modulo in modo da poterlo testare, se funziona e soddisfa perfettamente le nostre specifiche! In caso contrario, desideriamo l'opzione di restituirlo e ottenere un rimborso.

Intermedio:

• Sostituzioni di classe: il modulo sostituisce le classi principali?

  In generale, un buon modulo non dovrebbe sovrascrivere alcuna classe principale, piuttosto dovrebbe usare gli osservatori.

  Uno dei motivi è che può rendere difficile l'aggiornamento di Magento. Inoltre, altri moduli potrebbero dipendere da un output di una determinata funzione e questo modulo ne fornisce uno diverso.

  A volte non è possibile farlo, in tal caso, dovrebbe esserci un'ottima ragione per ignorare una classe principale.

• Aggiornamenti del layout: il modulo modifica alcune delle mie impostazioni del layout?

  Alcuni moduli modificano le impostazioni del layout sul tuo sito (ad esempio: pagina del prodotto), assicurano che non interrompa il layout corrente e se fa ciò che sarebbe necessario (leggi: quanto tempo ci vorrà) per risolverlo .

• Modifiche al modello: il modulo include modelli che cambiano il mio progetto attuale?

  Questo modulo introdurrà nuovi modelli? Se sì, romperanno il mio design? Quanto tempo ci vorrà per avere il design come vogliamo?

• Dipendenze: il modulo dipende da qualsiasi altro modulo?

  Se il modulo dipende da altri, dobbiamo assicurarci che siano presenti e installati. Inoltre, dobbiamo chiederci, vogliamo disattivare il modulo da cui dipenderà in futuro?

Avanzate:

• Script di aggiornamento SQL: il modulo aggiorna il DB in qualche modo?

  Una volta che un modulo aggiorna il database, dobbiamo accertarci di alcune cose.

  Aggiorna una tabella principale? Se sì, non va bene, ci piacciono i nostri database puliti e pronti per l'aggiornamento.

  Memorizza le informazioni in modo sensato? Se vogliamo ottenere noi stessi i dati grezzi dal database, saremmo in grado di dargli un senso?

• Eventi: il modulo osserva o invia eventi?

  Se un modulo invia o osserva eventi, vogliamo sapere:

  Quali eventi sta osservando / inviando? Questo influirà su un altro modulo che funziona nel sistema. Ad esempio, se uno dei nostri moduli modifica il nome dei nostri prodotti sotto carico in maiuscolo e questo modulo aggiunge la parola "libero" al nome del prodotto sotto carico, come funzionerà? La parola "libero" uscirà anche in maiuscolo?

• Revisione del codice - Il modulo utilizza tecniche di codifica accettabili?

  Questo ha più a che fare con le tecniche di codifica PHP che Magento.

  Il codice utilizza i blocchi Try / Catch?

  Il codice sfugge all'input dell'utente?

  Le specifiche di questo dipendono davvero dal nostro livello di abilità / requisiti.

• Potenziali problemi - Quali potenziali problemi possono sorgere a seguito dell'installazione di questo modulo?

  Prova a immaginare i cinque principali problemi che potrebbero sorgere se installiamo questo modulo, per quanto sorprendente, in quanto fornisce davvero una visione del progetto nel suo insieme.

Linea di fondo:

Tutte queste cose sono belle da avere in un mondo ideale, in scenari del mondo reale dobbiamo fare questa cosa chiamata 'compromesso' :)

Inoltre, queste linee guida sono pensate per essere un aiuto per noi, non per ostacolarci, di conseguenza se stiamo installando un solo modulo, diciamo un modulo di condivisione sociale, ed è per un cliente che ha bisogno di una semplice configurazione del sito, lì non ha senso fare un sacco di ricerche.

In altre parole: si tratta di essere efficienti con il nostro tempo, se l'uso di questa (linea guida) mi aiuta a risparmiare tempo a lungo termine, usalo, se non lo lasci cadere e risparmia la tua sanità mentale.

Alcune bandiere rosse "cattive pratiche" specifiche di Magento sono:

• qualsiasi codice in app/code/local/Mage
• modelli sovrascritti (file app/designgià esistenti nel core)
• riscrive di classi essenziali come catalog/product. In generale, guardo attentamente ogni riscrittura, per vedere se avrebbe potuto essere evitato
• gravi violazioni degli standard di codifica Zend / Magento. Sebbene si tratti solo della formattazione del codice, concludo che gli sviluppatori che sono incuranti degli standard saranno molto probabilmente incuranti anche di altre cose, più importanti.
• modifiche nelle tabelle del database principale
• testo codificato nei modelli (non utilizzando il meccanismo di traduzione) e altrove
• logica di business nei template (regola empirica: qualsiasi occorrenza Mage::getModelnella directory dei template è di solito un brutto segno)

Alcune bandiere rosse relative a PHP (questa è una lista molto selettiva e incompleta):

• eventuali avvisi e avvertenze con segnalazione errori abilitata ( E_STRICT)
• utilizzo @dell'operatore
• non disinfettare i dati utente prima dell'output

Alcune bandiere rosse relative alle prestazioni:

• query del database all'interno dei loop
• caricamento di un'intera raccolta solo per usarne una parte

Cerca anche odori di codice generali , che non sono necessari bandiere rosse ma aiutano a stimare la qualità complessiva.

Passaggio 1: il tuo cliente può permettersi di supportare questa estensione se lo sviluppatore diventa AWOL?

In caso contrario, non è possibile utilizzare l'estensione.

In caso affermativo, passare alla valutazione dell'estensione.

La brava gente di Inchoo ha un articolo sull'analisi del codice del modulo di terze parti. L'articolo menziona riscritture di classe, cron job, aggiornamenti di layout e osservatori di eventi.

Ho trovato che il codice dell'osservatore di eventi ha il potenziale per il massimo delle prestazioni. Cerca il codice di terze parti ad alta intensità di risorse che viene eseguito per eventi inviati di frequente. Eventi come controller_action_predispatch o caricamenti di raccolte.

Uso questo modulo di utilità di Prattski per avere una bella panoramica di riscritture e osservatori.

Avere modelli e risorse skin posizionati in default / default (o pro o enterprise) invece che base / default è piuttosto fastidioso.

Il codice offuscato è qualcosa a cui fare attenzione: cercare le chiamate a eval (), base64_decode () e simili. Questo viene spesso utilizzato per la convalida della licenza, ma può essere dannoso o spaventoso: ho visto almeno un componente che ha valutato il codice arbitrario da un feed RSS.

Cerca le chiamate dl () - almeno un componente del gateway di pagamento che ho visto richiede l'installazione di un'estensione PHP per effettuare le sue connessioni!

Hai ragione.

Sfortunatamente non c'è magia: devi testarli, controllare il codice per vedere se è ben sviluppato, avere un buon supporto per i moduli commerciali grazie al loro forum o rapidità per rispondere alle tue domande ...

Ci sono alcune recensioni su Magento Connect e la popolarità di un'estensione può aiutare a sapere se è preziosa o meno, ma onestamente puoi trovare moduli molto popolari con molti bug. Ho avuto un buon esempio la scorsa settimana con un modulo MailChimp, principalmente ben fatto ma ho dovuto correggere alcuni bug e fornirli allo sviluppatore. Ci sono sempre dei rischi, devi testare.

WebShopApp ha avuto l'idea di spingersi in questa direzione, intendo portare una piattaforma per ottenere buone informazioni sui moduli. L'idea era di spingere Magento in questa direzione. Quindi la qualità del modulo è una vera domanda.

Il mio consiglio: presta estrema attenzione ai moduli che dispongono di script di installazione / aggiornamento che modificano i valori nelle tabelle principali perché non è sempre facile ripristinare quel tipo di modifiche.

Il test n. 1 che posso trovare è quello di trovare un exploit zero-day nel loro codice (di solito non molto difficile con le estensioni Magento), riportare solo il danno risultante di un exploit finto al loro team di sicurezza (senza fornire alcuna indicazione di quale parte del codice è vulnerabile) e avvia il cronometro, perché è esattamente ciò che accadrà quando il tuo sito viene violato. Quando il loro personale di supporto richiede l'accesso FTP e mysql globale, rifiuta educatamente affermando che è in violazione del PCI-DSS e si offre di consentire loro di avere accesso in sola lettura al repository del codice sorgente.

Il test n. 2 che eseguo è di richiamare il fornitore e prenderli alla sprovvista. Chiedi loro che tipo di test comportamentali / di unità eseguono, quale sistema di controllo del codice sorgente usano, su quali versioni di PHP testano, su quali versioni di Magento sono testate, su quali server Web sono testati, indipendentemente dal fatto che utilizzino o meno il browser -stack per testare componenti front-end, ecc ... Se il venditore non sa di cosa stai parlando, tace o vuole "ottenere un esperto per inviarti una risposta", corri come l'inferno perché molto probabilmente usano i numeri i file zip per "controllo versione" e correggono i bug solo 3 mesi dopo che i loro clienti li segnalano.

Parlando del PCI-DSS, anche tutte le modifiche al sistema devono avere una strategia di inversione. Con i moduli che aggiungono colonne non annullabili alle tabelle principali, ciò diventa quasi impossibile pur mantenendo una strategia di inversione che avrebbe superato un controllo. Esegui da qualsiasi modulo che causerà problemi (leggi: Errori SQL) quando disabilitato.

PCI-DSS v3

6.4.5.4 Procedure di back-out.

Verificare che siano preparate procedure di back-out per ogni modifica campionata.

Per ogni modifica, dovrebbero esserci procedure di back-out documentate nel caso in cui la modifica abbia esito negativo o influisca negativamente sulla sicurezza di un'applicazione o di un sistema, per consentire il ripristino del sistema al suo stato precedente

Questo, oltre alle altre risposte. IMO dovrebbe esserci un muro di vergogna per alcune delle stronzate pericolose che sono state generate su questa piattaforma.