Usiamo passlib per criptare con sha256 la password dell'utente, e aggiungiamo anche un metodo opportuno al modello degli User per verificare la password con quella criptata.

Valutare come integrare cloudinary, o un servizio analogo, se possibile, per non avere immagini su disco in locale in produzione.

http://cloudinary.com/

La seconda risorsa di cui ho bisogno per usare le immagini e' la Picture.

• Picture [/pictures/uuid:picture_uuid]
  GET -> ritorna l'immagine
  DELETE -> elimina l'immagine

(http://flask.pocoo.org/docs/0.12/api/#flask.send_from_directory)

Abbiamo bisogno di due risorse per gestire le immagini:

• ItemPictures [/items/uuid:uuid/pictures]
  GET -> ritorna la lista di pictures uuid di un item
  POST -> upload di immagine per quell'item

Dobbiamo scrivere gli schema di marshmallow anche per Order e OrderItem. La situazione e' un pochino piu' complicata di un semplice Address perche' le tabelle Order e OrderItem sono intrecciate, e nello schema questo si deve riflettere per fare la validazione e il dump.

http://marshmallow.readthedocs.io/en/latest/api_reference.html#module-marshmallow.fields
http://marshmallow.readthedocs.io/en/latest/nesting.html

Al momento non è possibile eseguire questa sequenza di comandi:

PYTHONPATH=. scripts/init-db.py
PYTHONPATH=. python scripts/demo-content.py
PYTHONPATH=. python scripts/demo-content.py

poiché si ottiene sul secondo demo-content:

peewee.IntegrityError: UNIQUE constraint failed: item.uuid

la ragione è che usiamo un seed che è hardcodato nel sorgente. E' necessario modificare il demo-content perché il seed (numero intero) possa essere passato allo script come argomento command line gestito tramite argparse. Il valore passato allo script dovrà andare a rimpiazzare i valori usati attualmente nel sorgente (sia per random che per Faker).

A differenza delle put, le patch accettano elementi parziali, e vanno a modificare solo gli attributi che cambiano, senza distruggere e ricreare l'intero oggetto.

Adesso abbiamo gli Schema di marshmallow, e in classe base models BaseModel abbiamo verify_json (classmethod). Possiamo cominciare a sostituire i vari request parse con la verify_json, partendo appunto da address.
Notando che:

1. stiamo usando marshmallow per gli schema, schemas.py
2. stiamo usando jsonschema per la validazione del json, in particolare jsonschema.validate che ritorna una ValidationError se il json non e' conforme allo schema.
3. possiamo prendere il messaggio di errore dall'eccezione (in un try...except) e ritornare BAD_REQUEST e il messaggio se il json dato dal client non e' valido

def open_with_auth(self, url, method, email, password, data):
        return self.app.open(
            url, method=method, headers={'Authorization': 'Basic ' + base64.b64encode(
                bytes(email + ":" + password, 'ascii')).decode('ascii')}, data=data)

Credo possa essere sostituito con un metodo che generi la stringa per Headers da passare alla chiamata necessaria nel test (che sia self.post, self.get, etc..) invece che complicare il tutto con tutti questi parametri.

Qualcosa del tipo:

def authenticated_headers(self, email, password):
    return {
        'Authorization': 'Basic ' + base64.b64encode(bytes(email + ":" + password, 'ascii')).decode('ascii')
    }

Non è stato testato il codice di recupero di un singolo ordine.

Utilizzare marshmallow-jsonschema per creare i json schema relativi a come sono strutturati i dati delle richieste.

class AddressesResource(Resource):
    def post(self):
        [...]
        parser.add_argument('user_id', type=utils.non_empty_str, required=True)
        [...]

        address = Address.create(
            uuid=uuid.uuid4(),
            user=user,
            [...]
        )

        return address.json(), CREATED

Viene richiesto il parametro user_id ma viene restituito user, questo crea complessità aggiuntiva nella gestione dei test rendendo difficile controllare i dati di invio e di ritorno rapidamente.

https://flask-httpauth.readthedocs.io/en/latest/

Possiamo autenticare le chiamate rest con HTTPBasic Auth, andando a mettere negli header delle richieste le informazioni username@password utilizzando flask-httpauth.
Al momento saranno da proteggere le chiamate PUT e DELETE dell'utente (solo un utente loggato potrà farle)

E' necessario creare un modello Address che rappresente il concetto di "indirizzo di spedizione". Un utente (modello User) puà avere più address, ma un address ha un solo utente possibile. Un address ha nazione, città, cap, indirizzo, numero di telefono, nome e cognome. E' necessario aggiungere l'address agli script di init-db e demo-content.

Gli item possono avere delle picture. Un item puo' avere piu' picture, una picture puo' avere un item solo.
Una picture ha un uuid, una extension e un link a item.

• Crei un test che controlli una cosa: se l'utente non e' superuser e prova a creare e modificare item, non possa.
• Le API di item in modifica devono funzionare solo se l'utente e' superuser
• Fixa gli altri test che c'erano

Dobbiamo avere una variabile di ambiente (in .env) ENVIRONMENT, che di default sia dev.
In modalita' dev usiamo sqlite come database, e nulla cambia.
In modalita' production invece dobbiamo usare postgres.

https://swifthorseman.com/2015/06/18/deploying-a-flask-app-with-peewee-to-heroku/
http://peewee.readthedocs.io/en/latest/peewee/database.html#using-postgresql

Abbiamo la put, che sostituisce completamente un address con un altro.
Implementiamo anche la patch, che permette di avere sostituzioni parziali.

Usiamo marshmallow per validare i dati delle richieste, creando opportunamente degli schema per le varie viste presenti.

Dovrà essere possibile creare, modificare, cancellare o visualizzare (il singolo elemento o la lista) degli Order. Sarà necessario realizzare anche adeguata suite di test.

Ci sono dei test che fanno a mano la Item.create invece di usare il nostro standard self.create_item. Fixiamo.

In models la classe base dovrebbe implementare la refresh. Ovvero una funzione che, chiamata su un oggetto peewee, vada a ricaricare i suoi valori presi dal database.
Questo:
item = User.get(User.uuid == item.uuid)
diventa questo:
item = item.reload()

• schema per i Favorite in schemas
• metodo get_schema
• test della verify_json

Dovrà essere possibile:

• creare un nuovo address associato ad un utente (POST /addresses/)
• modificare un address esistente (PUT /addresses/<id>)
• ottenere un address esistente (GET /addresses/<id>)
• eliminare un address esistente (DELETE /addresses/<id>)

Sarà necessario realizzare gli unit test per verificare il corretto comportamento delle viste.

E' necessario aggiungere un campo category al modello degli Item, e ovviamente anche aggiornare le viste e i test per tenerne conto. Inizialmente la categoria sarà una semplice stringa, in un futuro creeremo un modello e delle viste dedicate.

Tutti i test si aprono a mano il test_client, si setuppano il database, etc... È tutto codice ripetuto che va fattorizzato e raggruppato in una classe di utility che tutti i test devono derivare.

Aggiungiamo il campo status allo User, che sara' enable per ogni utente standard. Lo status potrebbe pero' essere blocked per gli utenti bloccati, e deleted per gli utenti cancellati.
La delete di User adesso dovrebbe cambiare il campo state a deleted.
Uno user si puo' autenticare solo se e' enable.

C'e' da guardare Marshmallow e andare a scrivere in schemas.py gli schema di Address, User e Item, facendo attenzione agli attributi che andiamo prendere, alcuni sono solo in dump, altri solo in load, etc...

Aggiungiamo un README.md con tutte le informazioni per lanciare il demo content, gli scripts, dove sono cosa fanno etc...
Usiamo il formato markdown di github.

Ogni item dovrà essere dotato di un campo availability, numero intero che indica la quantità di item a disposizione. Un utente potrà fare ordini solo di item che hanno disponibilità > 0 e ogni
ordine effettuato dovrà modificare in modo opportuno la disponibilità. E' da gestire anche il caso in cui una PUT su un ordine cerchi di aggiungere della quantità per un item che non ne ha, e in quel caso il server dovrà rispondere con un 403 (forbidden)

Sarà necessario creare due script (da mettere dentro la directory scripts):

• il primo chiamato init-db.py dovrà andare ad eliminare il database corrente e ricreare tutte le tabelle;
• il secondo chiamato demo-content.py dovrà andare a generare alcuni utenti, ordini e item di prova. Usiamo Faker per generare i dati, specificando il seed in modo che i dati generati siano riproducibili.

Entrambi gli script NON richiederanno argomenti a linea di comando.

...come per esempio address

• Account heroku
• Aggiungere nel .env le config di mailgun e usarle per avere mailgun
• Creare un modulo che abbia un'api per mandare delle mail
• Usiamo i template html di flask per il corpo dell'email
• La funzione send_email deve prendere come parametri un template (ce ne sara' uno di default), e uno kwargs di parametri chiave-valore che saranno poi sostituiti nel template, e i parametri obbligatori di mailgun (titolo?)

Esempio:

try:
    utils.non_empty_str(args['name'], 'name')
except ValueError:
    return None, BAD_REQUEST

Può essere una semplice modifica all'argument:

parser.add_argument('name', type=utils.non_empty_str, required=True)

Per supportare heroku occorre:

• avere due file, un Procfile e un Procfile.dev con le righe di comando necessarie ad avviare il server rispettivamente su heroku e in locale
• un file runtime.txt con specificata la versione di python che stiamo usando
• un file .env in locale, non committato, con le variabili di ambiente scritta in formato VARIABILE=valore

Esempio:

    def test_get__address_found(self):
        data_user = User.get()
        address_id_created = uuid.uuid4()
        Address.create(
            [...]
            )

        resp = self.app.get('/addresses/{}'.format(address_id_created))
        query = Address.get()
        assert resp.status_code == OK
        assert query.json() == json.loads(resp.data.decode())

In questo caso viene ignorato l'oggetto creato e viene confrontato il dato recuperato dal database (che c'è già, creato poco prima) con la risposta del server

Sarà necessario aggiungere il concetto dei favourites, che vuol dire:

• aggiungere un modello Favorites composto da una primary key che è lo User e un altra che è l'Item
• aggiungere un endpoint /favorites/ che supporti i verbi GET per elencare tutti gli item preferiti di un utente (utente che verrà ricavato dall'utente attualmente autenticato) e POST per crearne uno nuovo il cui id è specificato nel json della richiesta
• aggiungere un endpoint /favorites/<item_id> che supporterà il verbo DELETE per eliminare il preferito
• il modello dell'utente dovrà essere dotato di un metodo add_favorite(item) e remove_favorite(item) che vadano rispettivamente a creare o rimuovere un preferito

Dovrà essere possibile creare un nuovo Item, modificarlo, cancellarlo o visualizzarlo (il singolo Item o l'insieme di Item). Sarà necessario realizzare anche adeguata suite di test.

E' necessario aggiungere un flag admin boolean che discrimini utenti normali da quelli admin. Gli utenti creati attraverso la relativa API (in sviluppo) saranno tutti utenti normali, e gli utenti admin dovranno essere creati "manualmente" aggiungendo uno script nella directory scripts chiamato create_superuser.py e che, usando Click (http://click.pocoo.org/5/), richieda email e password del nuovo utente.

Deve essere possibile creare un nuovo utente, modificarlo o cancellarlo. Sarà necessario realizzare anche adeguata suite di test.

• Nuova tabella Reset
  code -> uuid primary key
  user -> foreign key user
  expiration -> date
  enable -> boolean
• POST /users/reset <- {"email": "...."}
  Il codice di questa post e' sempre okay no content.
  Questa post crea nella tabella Reset un record associato a questo utente, con un codice generato casualmente, una expiration date di un'ora, e lo user.
  Se esistevano altri code gia' emessi per questo utente, metterli tutti a enable == false. Solo un codice puo' essere valido alla volta.
• POST /resets <- {"code": "....", "password": "..."}
  Prende l'utente associato a quel code, che deve essere valido, e gli imposta la password. Il campo enable della Reset deve essere false.

Da capire perche' senza cascade=true crasha postgres, e con crasha sqlite

Uniformare il nome della viste degli items a quanto già presente per gli utenti, chiamandole rispettivamente:

 ItemsResource
 ItemResource

Rimuovere anche la funzione string_not_empty e utilizzare al suo posto la funzione non_empty_str che adesso è definita in views/user.py e che andrà spostata in un file utils.py

Il demo-content va aggiornato con Picture