Jump to content
Sign in to follow this  
Kaylas

Pannello scadenze e gestione clienti

Recommended Posts

Ciao a tutti,

Mi sapreste consigliare un buon pannello per poter gestire correttamente clienti/fatture e automazione?

 

Mi spiego meglio, l'idea iniziale era di andare su WHMCS, ma guardando in giro ho visto che ha un'alto rischio di sql injection ( siamo nel 2016 e c'è qualcuno che ancora non utilizza PDO? -_-" ), quindi ai fini della sicurezza l'ho scartato.

 

Alcune persone ho visto che consigliano Hostbill che non pare male, se escludiamo il fatto che la licenza parte da 999 dollari (lifetime) e al momento è completamente fuori budget.

 

Altri che consigliano boxbilling, ma la demo ufficiale in errore da diverse settimane non mi ispira molta fiducia :D

 

Requisiti:

  • Automazione
  • Gestione clienti
  • Gestione fatture / fatture ricorrenti
  • Gestione dei pagamenti via Paypal
  • Gestione scadenze / reminder

Grazie,

 

Share this post


Link to post
Share on other sites

 

 

Mi spiego meglio, l'idea iniziale era di andare su WHMCS, ma guardando in giro ho visto che ha un'alto rischio di sql injection ( siamo nel 2016 e c'è qualcuno che ancora non utilizza PDO? -_-" ), quindi ai fini della sicurezza l'ho scartato.

 

 

 

Veramente mi risulta che dalla versione 6 il problema sia stato risolto...

 

Infatti anche per sviluppo, consigliano di non effettuare più operazioni sul db attraverso query dirette, ma attraverso la loro libreria di API interne

Share this post


Link to post
Share on other sites

Veramente mi risulta che dalla versione 6 il problema sia stato risolto...

 

Infatti anche per sviluppo, consigliano di non effettuare più operazioni sul db attraverso query dirette, ma attraverso la loro libreria di API interne

 

Ottimo allora le fonti che avevo letto in giro erano vecchie, buono a sapersi.

 

 

Credo che WHMCS correttamente patchato con gli addon di Katamaze sia la scelta migliore.

Infatti mi stavo informando a riguardo

Share this post


Link to post
Share on other sites

Premesso che sono arrossito... :wub:

 

-- Inizio pippone

 

In un passato nemmeno troppo lontano, WHMCS ancora utilizzava delle API che sfruttavano mysql() ma già da tempo si è passati DBAL che è basato su PDO. Ciò detto, la fregatura è che anche se WHMCS è ora nella giusta direzione per quanto riguarda l'interazione con il database, moltissime terze parti (addon, gateway, registrar, action hook, server module ecc.) sono ancora scritte in mysql() e non tutti gli sviluppatori sono interessati a tornare sui propri passi e riprogettare le loro soluzioni per renderle sicure.

 

Penso che una parte di essi prenderà in considerazione la possibilità di abbandonare mysql() solo quando questa libreria sarà definitivamente rimossa da tutti i server. Un'altra parte, quella degli sviluppatori che io chiamo "fire and forget", semplicemente abbandonerà il progetto o si inventerà storie del tipo che è tutta colpa di WHMCS se non possono farlo (chiarisco che non è vero allora come non lo è adesso che non si possono utilizzare mysqli() o PDO per sviluppare in WHMCS). Questa tendenza è ascrivibile sia ad un certo tipo di sviluppatori che ad un certo tipo di utilizzatori di WHMCS. Ancora mi capita di vedere installazioni con WHMCS 3 e 4 che non vengono aggiornate, e che sono quindi vulnerabili, perchè per il cliente vige la regola del «basta che funzioni» e, con diversi giri di parole e sfumature, dello «sti ca**i della sicurezza» con varie scusanti «tanto ho pochi clienti», «è una cosa provvisoria». Sono gli stessi che poi vanno a lamentarsi su webhostingtalk.com o a scrivere recensioni negative attribuendo tutte le colpe a WHMCS.

 

Per esperienza personale il 99% dei distastri che accadono in WHMCS si possono ricondurre ad errori madornali degli amministratori, password oscene, directory admin non rinominate, cartelle templates_c, attachments e crons non spostate ad un livello superiore rispetto al www (molte backdoor entrano così), al rifiuto di aggiornare WHMCS ed applicare i security fix, al non sapere nemmeno dove si trovi l'encryption hash, terze parti fatte malissimo, al fatto che si dia troppo facilmente accesso FTP a sviluppatori trovati "a caso", spesso che lavorano per 4$ l'ora, su siti come Freelancer.com. Ci sarà un motivo se per la stessa soluzione alcuni chiedono 10$ ed altri 400$. Ad oggi, dopo aver messo le mani in centinaia di WHMCS, al netto delle cause prima elencate, ancora devo trovare un vero disastro che sia stato causato da WHMCS.

 

La cosa più brutta che ho visto fare è stata scaricarsi il database contestualmente all'encryption hash e avviare il trasferimento di tutti i domini del cliente, avere accesso completo Plesk/cPanel/FTP dei siti nonché accesso root a tutti i server e alle caselle email ufficiali. Il cliente era convinto si trattasse di una falla di WHMCS ed invece era stato un Indiano che gli aveva fatto un action hook mesi prima.

 

Ci sono poi moduli, anche molto utilizzati, che sono stati realizzati da sviluppatori sicuramente competenti su altri sistemi ma certo non su WHMCS. Ad esempio uno di questi per connettersi al database e fare le query utilizza una libreria di più di 20 MB :icon_eek: e per salvare i log un'altra da 8. Cioè WHMCS da solo occupa 40 MB nello zip e qui abbiamo 28 MB di codice solo per fare query e salvare un log tutte cose che WHMCS può fare out from the box.

 

Il segreto sta, come in tutte le cose, nell'utilizzare soluzioni corrette ed affidarsi alle persone giuste.

 

-- Fine pippone

 

Dopo tutto questo lungo pippone, mi sento di consigliarti di rivalutare WHMCS. Se sei un hosting provider o una web agency o un professionista che lavora nell'IT, WHMCS è una scelta corretta. È leader indiscusso del mercato penso da sempre, il più economico, più supportato e quello con la community di sviluppatori più attiva. Mi piace sempre fare questo parallelo: se devi fare un blog la soluzione numero uno è Wordpress anche se puoi usare Joomla. Se devi fare un hosting la soluzione numero uno è WHMCS anche se c'è Hostbill. C'è anche da chiarire un concetto. La community dei lamer, quelli che voglioni bucarti il sito, è certamente più attiva su WHMCS e Wordpress perchè li usano tutti. Lo stesso fatto che sono piattaforme di successo li rende appetibili sotto questo punto di vista. Quale lamer sprecherebbe un solo minuto del suo tempo per cercare di bucare una piattaforma come e107 che girerà si e no su un migliaio si siti? Questo non significa assolutamente che e107 sia più sicuro di Wordpress o WHMCS ma anzi il contrario. Comunque sia, se il budget non è un problema, un'alternativa potrebbe essere Ubersmith ma costa milioni di miliardi di euro al mese e francamente non lo trovo migliore di WHMCS. C'è anche Blesta.

 

Ultima cosa: WHMCS è incredibilmente espandibile. Il fatto che sia offuscato non ti limita in alcun modo e se trovi una persona che afferma il contrario semplicemente non sa come usarlo. Se per assurdo la NASA mettesse a disposizione delle API per il puntamento dei telescopi, potresti tranquillamente fare un modulo per la loro gestione.

 

p.s. Se ho fatto errori scusate ma ho la febbre :( e non so che fare... mi annoio... uffa...

Share this post


Link to post
Share on other sites

Entrambe ti danno accesso all'assistenza di WHMCS. Quelle prese da intermediari possono essere più economiche anche alla luce dei recenti cambiamenti nella loro politica dei prezzi. Di più non so dirti perchè ho sempre utilizzato solo le owned.

Share this post


Link to post
Share on other sites

 

La cosa più brutta che ho visto fare è stata scaricarsi il database contestualmente all'encryption hash e avviare il trasferimento di tutti i domini del cliente, avere accesso completo Plesk/cPanel/FTP dei siti nonché accesso root a tutti i server e alle caselle email ufficiali. Il cliente era convinto si trattasse di una falla di WHMCS ed invece era stato un Indiano che gli aveva fatto un action hook mesi prima.

 

 

Peggio della trama i un film di Dario Argento...  :sbav:

 

Questa storia è talmente folle (e da incubo) che meriterebbe che ce la raccontassi con qualche dettaglio in più... magari approfittando del fatto che hai la febbre e ti annoi!   :lode:

 

(A proposito: auguri di pronta guarigione!)

Share this post


Link to post
Share on other sites

chiarisco che non è vero allora come non lo è adesso che non si possono utilizzare mysqli() o PDO per sviluppare in WHMCS). 

 

Approfitto per chiederti, per chiarirmi un dubbio.

 

Non mi è chiaro *quanto* ci si possa permettere di *pasticciare* sul db usando direttamente mysql (o phpmyadmin).

 

Nel senso: la posizione di WHMCS è (giustamente) granitica: "tutte le operazioni sul db vanno fatte usando solo le internal API"

Il che, immagino, non solo per questioni di sicurezza, ma anche per questioni di rispetto ed integrità della logica dei dati.

 

Tuttavia ci sono molte operazioni di "ordinaria e straordinaria manutenzione" che sarebbe MOLTO più agevole fare direttamente lato db (penso, ad esempio, all'aggiornamento di anagrafiche dei clienti, all'importazione di domini ecc.)

 

Da un lato, vedo che anche Registrar "importanti", nei loro moduli, comprendono funzioni con query dirette al db (si tratta però di funzioni disponibili solo nel pannello admin di whmcs, quindi, tutto sommato, pochi problemi di sicurezza...)

Quindi, almeno da un punto di vista della logica dei dati, sembra che WHMCS possa "digerire", ad esempio, l'importazione di una nuova anagrafica cliente direttamente attraverso un banale "insert" nella relativa tabella, senza scomporsi troppo... però quello che non mi è chiaro quali siano i limiti con cui si possono eseguire queste operazioni in maniera "disinvolta"...

Share this post


Link to post
Share on other sites

Peggio della trama i un film di Dario Argento...  :sbav:

 

Questa storia è talmente folle (e da incubo) che meriterebbe che ce la raccontassi con qualche dettaglio in più... magari approfittando del fatto che hai la febbre e ti annoi!   :lode:

 

(A proposito: auguri di pronta guarigione!)

 

Semplicemente quell'Indiano nello svolgere il suo lavoro ha prima fatto due operazioni: scaricare il database via PHP (suppongo abbia scaricato solo le tabelle che gli interessavano ovvero tblservers, tblhosting, tblconfiguration, tbldomains, tblclients) aprire il file configuration.php e salvare l'encryption hash. Dopo aver completato il suo lavoro, avrà rivenduto a terzi i dati sottratti e questi, conoscendo l'hash, hanno potuto approntare un WHMCS fasullo dove girarsi tutto il WHMCS del cliente liberamente con le password in chiaro. Hanno richiesto gli auth code per trasferire i domini che gli piacevano e qualche cliente poco accorto ha dato seguito alla richiesta. Al contempo hanno inserito "cose" in alcuni server e siti ma di questo non so molto. Comunque erano tanti anni fa. Quando alla fine sono stati tagliati fuori, per settimane hanno continuato ad aprire ticket mascherati, nemmeno troppo bene, da domande di carattere commerciale allegando script che altro non erano che backdoor. Poi con Dirbuster tentavano di indovinare via bruteforce il prefisso di 6 numeri che WHMCS aggiunge agli allegati. Col mio PC di allora riuscivo a fare 4k di richieste al secondo... considerando che con 6 cifre ripetibili le combinazioni possibili sono 1 milione, in qualche minuto potevano scoprire dove si trovasse la backdoor da loro allegata ed accedere via FTP. Non ha aiutato il fatto che il webserver fosse non aggiornato e fin troppo permissivo.

 

Approfitto per chiederti, per chiarirmi un dubbio.

 

Non mi è chiaro *quanto* ci si possa permettere di *pasticciare* sul db usando direttamente mysql (o phpmyadmin).

 

Nel senso: la posizione di WHMCS è (giustamente) granitica: "tutte le operazioni sul db vanno fatte usando solo le internal API"

Il che, immagino, non solo per questioni di sicurezza, ma anche per questioni di rispetto ed integrità della logica dei dati.

 

Tuttavia ci sono molte operazioni di "ordinaria e straordinaria manutenzione" che sarebbe MOLTO più agevole fare direttamente lato db (penso, ad esempio, all'aggiornamento di anagrafiche dei clienti, all'importazione di domini ecc.)

 

Da un lato, vedo che anche Registrar "importanti", nei loro moduli, comprendono funzioni con query dirette al db (si tratta però di funzioni disponibili solo nel pannello admin di whmcs, quindi, tutto sommato, pochi problemi di sicurezza...)

Quindi, almeno da un punto di vista della logica dei dati, sembra che WHMCS possa "digerire", ad esempio, l'importazione di una nuova anagrafica cliente direttamente attraverso un banale "insert" nella relativa tabella, senza scomporsi troppo... però quello che non mi è chiaro quali siano i limiti con cui si possono eseguire queste operazioni in maniera "disinvolta"...

 

Non sei obbligato ad utilizzare DBAL come in passato non si era obbligati ad utilizzare unicamente la query syntax di WHMCS. Prima ancora che WHMCS passasse da quel surrogato di mysql (vulnerabile) a DBAL (sicuro perchè basato su PDO) già da anni usavo PDO. Come vuoi connetterti al database lo puoi decidere tu.

 

WHMCS ha sempre avuto il problema di dover gestire una grossa parte di clienti completamente a digiuno di sviluppo web che si rifiutano di rivolgersi agli sviluppatori, che pretendono di mettersi al loro posto e che se non ci riesce si lamenta e dà tutte le colpe a WHMCS. È in quest'ottica che hanno aggiunto l'auto-updater, gli action hook per personalizzare la sidebar e la navbar, DBAL, quell'odiosa ed insopportabile sintassi Markdown e così via. Se sei uno sviluppatore queste cose tendenzialmente non sono state fatte per te. DBAL è più facile e documentato rispetto a PDO ma anche più lento di performance perciò perchè mai dovresti utilizzare il primo quando il secondo per te non ha segreti? Non hai nulla da guadagnarci e tutto da perderci.

 

Nel database puoi "pasticciare" direttamente via query o phpMyAdmin fintanto che sai quello che stai facendo. Così su due piedi mi vengono in mente questi fattori:

  • Devi conoscere la struttura delle tabelle, quali di esse sono collegate e come
  • Devi conoscere i trigger. Ci sono delle azioni che si triggerano (attivano) o che ci si aspetta che si attivino prima o dopo una determinata operazione nel database. Ad esempio se non aggiungi il cliente via API (AddClient) ma direttamente con una query, devi tener presente che l'azione "Invia email di benvenuto con le credenziali al cliente" non si triggera. Stesso discorso se aggiungi via query un hosting Plesk con tanto di username, password, server e status active. Questo non porta alla creazione dell'hosting. Aggiungere una transazione a saldo di una fattura, non porta la fattura a diventare Paid. Ovviamente questi sono esempi stupidi ma ce ne sono di altri molto più subdoli
  • Evitare i paradossi. Alcune operazioni nel database devono essere svolte in un preciso ordine. Non puoi ad esempio creare prima gli item della fattura e dopo la fattura oppure eseguire un'operazione su un record che non ancora esiste nel database ma che verrà creato un istante dopo

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×