Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  2 6399
Jeg har en nettside, den er ikke særlig seriøs, men brukes til min egen utvikling innen programmering, API etc. Jeg tenkte å inkludere en «login» funksjon til meg selv, kanskje lage det slik at jeg kan oppdatere fra en egen side; dette finnes fra før, noe jeg er aldeles klar over – men jeg vil heller lage og lære. Min server kjører Ubuntu 20.04, kjører Apache2 og har allerede et API kjørende, skrevet i Python. Dette har jeg skrevet om tidligere, men for å gjøre det kort et det et API hvor bilder legges opp via FLASK, prosesseres med ML og et svar blir sendt tilbake.

Til saken
Innlogget «trenger» ikke være veldig sikkert, men jeg tenkte like gjerne å gjøre det sikkert. Da forstår jeg at FLASK REST jwt kan være en løsning? Og det kan da brukes routing. Databasen jeg, for øyeblikket bruker, er MariaDB – er dette passende til slike oppgaver? Og om la oss si sqlalcmy passer bedre til passord og brukernavn, men MariaDB passer bedre – er det da noe særlig å bruke to databaser i et API? Føler at det fort blir rotete.
SQLAlchemy er en ORM, den gjør det enklere å aksessere dataene lagret i en database, men er ikke i seg selv en database. Om du bruker SQL direkte eller SQLAlchemy til å lagre/hente informasjon om brukere har lite å si her.

Når det kommer til brukere så må du passe på at passord lagres forsvarlig, det vil si hashet og saltet med en treg hashfunksjon. Se for eksempel https://exploreflask.com/en/latest/u...ring-passwords for et fint eksempel med bcrypt. Der finner du forøvrig også et eksempel på hvordan du kan bruke SQLAlchemy til å lettere aksessere dataene i databasen.

Om du ikke har behov for en JWT vil vanlig sesjonshåndtering være mer enn godt nok. Antagelig er enkleste, og tryggeste, veien til mål å bruke et bibliotek der dette allerede er trygt håndtert for deg. Med lett googling fant jeg flask-login: https://flask-login.readthedocs.io/en/latest/
det finnes mange gode måter å løse dette problemet på - litt avhengig av hva du trenger av funksjonalitet.
Trenger du å kunne lage flere brukere? I så fall trenger du nok en database. Om du egentlig bare trenger en passordbeskyttet side så blir det overkill. Da er det nok enklere å bare hardkode det.

Viktigste er å huske på at du aldri burde lagre passord i klartekst noen plass. Hverken hardkodet i koden eller i databasen. ALLTID bruk en hashing-funksjon . Når du skal sjekke om passordert er riktig bare kjører du inputen fra brukeren gjennom samme hashing-funksjon og sammenligner returverdien med det hashede passordet. Veldig mange biblioteker har ferdige funksjoner for dette. F.eks. kan du gjøre detm ed bcrypt i flask:

Kode

pw_hash = bcrypt.generate_password_hash('hunter2') # returns the hash of the password
bcrypt.check_password_hash(pw_hash, 'hunter2') # returns True
- MariaDB er en grei database. Det går fint å bruke den. SQLAlchamy er det opp til det om du ønsker bruke eller ikke. Selv likte jeg det ikke - mens andre synes det er kjempe bra. Spørs litt hvordan man liker å håndtere databaser.
- JWT er veldig populært for tiden, men som NIne sier, vil jeg anbefale å heller se på sesjoner. Det er mer enn godt nok til ditt bruk.

Jeg ville tatt det stegvis. Start med å lage en sesjonsbasert innlogging hvor passordet er hardkodet:
- Har hash passordet du ønsker og lagre hashen i en variabel i appen
- Når brukeren logger inn sammenlign mot hashen
- Hvis passordet er gyldig: Generer en ny sesjonsID (bruk gjerne en hash her og, så den ikke kan gjettes)
- Lagre hashen i minnet (f.eks. i en liste eller et map). På sikt (når du får skal støtte flere brukere) vil du også lagre info om hvilken bruker denne sesjonsIDen er tilknyttet.
- Returner HTTP-kallet med en header eller cookie (helst header av sikkerhetshensyn) som f.eks. X-SESSION-ID: [GENERERT_SESSION_ID]
- Alle fremtidige kall fra frontenden må da sende ved denne på kallene sine
- Backenden sjekker at SESSION-ID er gyldig på alle kall som skal være "beskyttet"