Scan Session and Scan Manager (2.2.1, 2.2)

Aperta
  • Qualcosa non va?
#44 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
mysql, python
Ambito
backend, databases, networking

Direzione di ricerca

Start by reading the referenced design sections 2.2.1, 2.2, 4.3, 6.1, 6.3, and 10, then review the dependencies in #23, #36, #15, and #16. Implement and test the scan session steps and background sequence with the named fakes and InMemoryRepository. Done means progress and outcomes are recorded, concurrent scans are refused with the starter named, and unavailable methods or crashes produce the specified outcome.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

backend High Priority Parent task

What to do

Turn the separate pieces into one scan: open a scan session for the user who asked, run Host Discovery (#23) and Save Discovered Devices (#36) in order as a background job, report progress while it runs, and close the session with an outcome (success, partial or failed). Only one scan runs at a time, and users can keep browsing while it does.

Background

  • Spec: WF-01, WF-06, FR-01, FR-11, FR-13 (scan status and errors), OUT-06, NFR-06 (useful results when optional methods are unavailable), CM-09 (search and filter during a scan), CM-11 and CM-15 (one scan at a time, and who started it), SEC-11, SEC-14, SEC-15
  • System design: 2.2.1 Scan Session Controller (2.2.1.1 Open, 2.2.1.3 Report Status, 2.2.1.4 Close; 2.2.1.2 Maintain Scan Settings is left for later), 2.2 Scan Manager; section 10 (concurrency); section 4.3 and Figure 5a (scan control flow)
  • OOD: ScanIdentificationService.runScan(), Scan.start() / complete() / fail(message), the scan sequence (design doc section 6.3)

Rules for every subtask

  • One scan at a time (CM-15). Starting a scan while one is running is refused with a message naming who started the running one.
  • Scans run in the background inside the server process (CM-09), so the request that starts one returns at once. The UI polls the status (2.2.1.3).
  • Every scan records the user who started it (CM-11), the scope, the settings used and the start and end times.
  • A scan always ends with an outcome, even if it crashes: success, partial (finished, but a method was unavailable or some hosts failed) or failed (nothing useful done), with an error message (OUT-06).
  • One unavailable method never fails the whole scan (SEC-14, NFR-06). If ping is unavailable but the ARP cache works, the scan continues and ends partial.
  • Network work and database work stay separate: reference data is loaded once at the start (3.2.1), and the database is only touched in short transactions (OOD 5.1).
  • No alerts are sent here. The Scan Manager returns what happened (including "scan failed"); the Application Controller sends alerts after the outcome is saved (design 6.1 rules, SH-3, M6).
  • Unit tests use fakes (FakeNetwork, the fake ARP reader, InMemoryRepository), so a whole scan can be tested without a network or MySQL.

Subtasks (in order)

  1. Open scan session (2.2.1.1)
  2. Close scan session (2.2.1.4)
  3. Report scan status (2.2.1.3)
  4. Scan Manager (2.2): run the phases as a background job, plus the checkpoint script

Done when

  • One call starts a scan on your network; it runs in the background while the status shows its progress
  • When it finishes, the devices are saved (as in #36), and the scan row shows who started it, when it started and ended, and its outcome
  • Starting a second scan while one is running is refused, naming who started the first
  • With ping unavailable (for example, blocked), the scan still completes from the ARP cache and ends partial
  • A crash halfway through still closes the scan as failed with the error message
  • Unit tests pass without a network or database

Depends on

  • #23 Implement Host Discovery
  • #36 Save Discovered Devices
  • #15 Network Data (3.1: storing scans)
  • #16 Reference Data (3.2.1: loading reference data once per scan)

Blocks

The minimal Application Controller, API and scan screens (next parent), which lets a user start a scan from the browser.

Lingua principale
Python
Stelle
1
Fork
1
Merge medio
9h 31m
PR unite (30g)
36

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Bearkat-Professionals/Software-Engineering-Project

Tutte le issue di Bearkat-Professionals/Software-Engineering-Project

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.