Panel klienta WaveHost
Pannello cliente di un provider di hosting: ordine e gestione di VPS e server dedicati, wallet, fatture e programma referral. Uno stack moderno con autenticazione sicura e collegamento al pannello di gioco tramite un handshake sicuro. Il cliente gestisce tutto da un unico posto.
Il pannello cliente di un provider di hosting: ordinare e gestire VPS e server dedicati, un portafoglio, fatture e un programma di referral. La parte più interessante è il collegamento sicuro a un pannello di gioco separato, perché un cliente non si logghi due volte e gli account si colleghino senza il rischio di agganciarne uno sbagliato - tramite un handshake HMAC firmato.
Introduzione
WaveHost è un provider di hosting che aveva bisogno di un unico posto per i suoi clienti: ordini un server, paghi, fai referral, tutto dallo stesso pannello. Questa parte da sola è lavoro artigianale che avevamo già fatto in passato. La vera sfida stava accanto: dal provider girava già un pannello di gioco separato con i propri account, e questi due mondi andavano collegati in modo che il cliente sentisse un solo sistema, non due.
La cosa più semplice sarebbe far loggare le persone due volte e collegare un account a mano via e-mail. Ma è una strada diretta verso gli errori, e con il collegamento degli account un errore ha un prezzo concreto: agganci a qualcuno un account altrui e hai un problema che un normale scusa non può annullare. Volevamo un collegamento di cui ci si può fidare. Questo caso di studio parla soprattutto di quel collegamento.
Tutto da un unico posto
Il fondamento del pannello è la gestione a cui il cliente torna ogni giorno. L'ordine e la gestione dei server coprono sia i VPS sia le macchine dedicate, con il loro stato e la loro configurazione visibili in un'unica vista. Il cliente non salta tra strumenti per controllare cosa ha e in che stato è.
Attorno a questo vive il resto della gestione. Il portafoglio e le fatture stanno l'uno accanto alle altre, così che saldo, pagamenti e documenti formano un insieme unico, e non tre schede separate da conciliare da soli. Il programma di referral aggiunge un link di referral e un flusso di commissioni chiaro, agganciato allo stesso portafoglio. Il tutto poggia su uno stack moderno con autenticazione sicura, perché questo è un pannello in cui ci sono soldi e accessi ai server.
Un login invece di due
Il nocciolo del progetto è il collegamento del pannello cliente con il pannello di gioco esistente. Dal punto di vista del cliente il problema è banale e irritante al tempo stesso: due account, due login, due mondi che non gli interessano, perché lui vuole semplicemente gestire tutto in un unico posto. Dal punto di vista ingegneristico è proprio la parte in cui è facile fare qualcosa di pericoloso.
La soluzione ingenua è: che il cliente indichi il suo login del pannello di gioco e noi lo agganciamo. Il problema è che in questo modo chiunque potrebbe indicare il login altrui e agganciarsi a un account che non è suo. Il collegamento manuale via e-mail è lento e altrettanto bucato. Ci serviva un modo in cui un sistema dimostra all'altro l'identità del cliente, senza fidarsi di nulla che passi per il browser.
Una stretta di mano firmata
La soluzione è un handshake basato su HMAC. Quando il cliente clicca su "collega account" nel pannello WaveHost, il pannello genera un link che porta l'identificativo dell'utente, un timestamp e una firma calcolata con un segreto che conoscono solo i due pannelli. Il pannello di gioco riceve questo link, ricalcola la firma con il proprio segreto e confronta. Se coincide, sa che la richiesta è davvero partita dal pannello WaveHost e non da qualcuno che ha falsificato l'URL.
Ciò che conta è ciò che il browser non vede mai. Il segreto non lascia i server, quindi anche chi osserva o intercetta il link non può calcolare una firma valida per un identificativo altrui. Il timestamp chiude la seconda falla: il link è di breve durata, e il pannello di gioco respinge semplicemente un token scaduto, così un link intercettato non può essere usato più tardi.
Il link che collega gli account porta una firma HMAC e un timestamp. Il pannello di gioco respinge un token scaduto o con una firma errata, così un link intercettato o falsificato non aggancerà un account sbagliato. Il segreto lo conoscono solo l'una e l'altra parte, mai il browser, ed è per questo che la comodità non si può barattare con una falla.
Perché un link falsificato non funzionerà
Vale la pena scomporlo in scenari, perché solo allora si vede che la comodità davvero non costa sicurezza. Qualcuno sostituisce l'identificativo nel link con un altro, per agganciarsi a un account che non è suo. La firma smette di coincidere, perché è stata calcolata per un identificativo diverso, e una nuova non si può generare senza il segreto. Il pannello di gioco respinge la richiesta.
Secondo scenario: qualcuno intercetta il link valido di un cliente e prova a usarlo. Qui salva la situazione il timestamp. Il link vive poco, quindi intercettato in ritardo è già senza valore, e il pannello di gioco tratta un token scaduto esattamente come uno falsificato. In entrambi i casi il confine viene verificato lato server, all'ingresso, e non nell'interfaccia, che si può sempre aggirare.
Prima e dopo il collegamento dei pannelli
| Aspetto | Pannelli separati | Dopo il collegamento tramite HMAC |
|---|---|---|
| Login | due | uno |
| Collegamento dell'account | manuale via e-mail | un clic |
| Rischio di agganciarne uno sbagliato | reale | respinto dalla firma |
| Segreto nel browser | - | mai |
Cosa offre davvero il prodotto finito
Il cliente conduce tutta la gestione da un unico posto. Ordina server, gestisce VPS e macchine dedicate, paga, fa referral e tiene d'occhio il portafoglio senza saltare tra strumenti. Il collegamento al pannello di gioco funziona con un clic invece che con uno scambio di e-mail, così i due sistemi del provider al cliente sembrano uno solo.
Sotto, questa comodità non è pagata con la sicurezza, perché l'handshake è di breve durata e firmato e il segreto non raggiunge mai il browser. Un link falsificato o intercettato non aggancerà un account sbagliato, perché il server presidia il confine all'ingresso, e non l'interfaccia. È esattamente il tipo di soluzione di cui il progetto trattava: semplice per il cliente, duro dove deve essere duro.
Altri progetti
Altri lavori della stessa categoria - scopri come affrontiamo sfide simili.
Hai un progetto simile?
Contattaci - il preventivo è gratuito e arriva entro un'ora.




