Segnalazione #84
Login form
0%
Description
Il form di login, oltre a username e password, deve utilizzare i possibili URL via settings.py, definiti in una lista di tuple nella forma (URL, DESCRIZIONE)
- Se il settings in questione contiene una sola voce, il form non deve mostrare la scelta, ma soltanto la descrizione ("Ti stai connettendo a {}")
- Se il settings in questione contiene piu' voci, allora deve mostrare una select con tutte le scelte possibili
Nella installazione centralizzata, nel settings faremo una query al db di tutte le scuole.
Related issues
Associated revisions
History
Updated by Christopher R. Gabriel about 8 years ago
- Status changed from Nuovo to Commenti
- Assignee set to Enrico Zini
Ho provato una implementazione, e' nel branch t84, a questo commit:
Nel log ho espresso dei dubbi: pareri?
Updated by Christopher R. Gabriel about 8 years ago
- Related to Segnalazione #89: Forzare https verso octofussd added
Updated by Enrico Zini about 8 years ago
Mi piace l'idea di avere una select, e se i server diventano molti lo si può sempre potenziare con javascript per avere del typeahead/autocomplete/select2 roba del genere.
Se l'utente deve poter scegliere un server non presente nell'elenco, o se il validatore glie lo deve impedire, dipende da cosa ci dobbiamo difendere: se l'utente scrive quel che vuole nel server, può usare octonet per aprire connessioni a host/porte at caso provenienti da octonet invece che da lui. In queste connessioni mandiamo solo quello che ha scritto l'utente nel form, quindi non c'è leak di roba interna a octonet, però uno può usare il form di login di octonet per fare traffico verso qualcuno a nome di octonet.
Uno potrebbe anche tirar su un server tipo-octofussd ma che dà risposte malvage a octonet, però non mi viene in mente come uno potrebbe sfruttare questa cosa: octonet fa poco di piú che prendere del json da una parte e girarlo dall'altra, e non mi risulta che esegua codice proveniente da octofussd.
Se c'è da difendersi da scenari di questo tipo, allora facciamo validare le macchine lato server. Mi sembra la scelta migliore se è una scelta possibile. Che dici, va bene a loro potersi collegare solo alle macchine conosciute da octonet?
Updated by Enrico Zini about 8 years ago
Sull'how to test, c'è octonet/tests.py
che ha già test per il form di login. Puoi aggiungere un test tipo:
with self.settings(OCTONET_MANAGED_SERVERS=[("…", "…")]): response = self.client.post(reverse("login"), data={"username": "root", "password": "root", "server_url": "http://example.org/conf/"}) self.assertEquals(response.status_code, 200) self.assertEquals(response.context["form"].errors["server_url"], "Invalid choice")
Updated by Enrico Zini about 8 years ago
- Assignee changed from Enrico Zini to Christopher R. Gabriel
Updated by Christopher R. Gabriel about 8 years ago
- Assignee changed from Christopher R. Gabriel to Enrico Zini
Si, la select2 servira' sicuramente visto che sono 83 scuole.
Il punto e' che l'utente si deve poter collegare unicamente ai server elencati nel settings di octonet, proprio per evitare che utilizzi octonet per mandare dati a chi vuole lui. Per cui direi che il form di login deve appunto, come dicevo sopra, verificare che quanto inviato alla POST, relaticamente all'url del server, sia una delle choices previste.
Updated by Enrico Zini about 8 years ago
Ci sto. Allora per ora lascio la tua implementazione del choices con quello che c'è nel SETTINGS
, e aggiungo solo unit test per la view.
Se in futuro vogliamo leggere l'elenco degli octofussd dinamicamente, e magari farci dare anche il nome della scuola e non solo l'url cosí facciamo una select piú bellina, apriamo degli altri ticket.
Updated by Christopher R. Gabriel about 8 years ago
Perfetto, poi mergia pure direttamente.
Il punto del settings e' proprio perche' io in quel "centrale" ci andro' a fare una querya a db, prendendo su tuple tipo (url, nome scuola), dal database di octomon (come facevamo sul vecchio octonet)
Fixed login form validation after migration to a ChoiceField. refs: #84