I’m fond of Flask. It was a breath of fresh air when it came out, and most of my Python open-source work is based on it.

Across all projects, Python 3.6+ is now required, and comprehensive type annotations are supported. At a glance, I’d say that the biggest news is async views in Flask 2. Work has also been done around Werkzeug Request and Response classes to allow for better sync and async in the future (it’s not a public API yet.) Jinja, Click and ItsDangerous come with a lot of new niceties. Details are available on the Pallets website.

Flask is, of course, the giant on which shoulders the whole Eve project rests. To say that the Pallets team has been working hard at the forge is an understatement—huge congrats to all of them.

So what is the Resource Owner Password Credentials Grant pattern? According to the official RFC:

The resource owner password credentials (i.e., username and password) can be used directly as an authorization grant to obtain an access token. The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application).

A typical use case would be when the remote API maintainer controls the client application. Say that you have a REST API being consumed by your own iOS, Android, WinPhone, desktop or web applications. Users register to your service by creating their accounts. Then, they consume the service using your applications.

Even though this grant type requires direct client access to the resource owner credentials, the resource owner credentials are used for a single request and are exchanged for an access token. This grant type can eliminate the need for the client to store the resource owner credentials for future use, by exchanging the credentials with a long-lived access token or refresh token.

So let’s get back at the proprietary client scenario. The user has just installed the application on his/her device. On first run he/she is asked to provide his/her username and password. These are sent to the OAuth2 server through a SSL/TLS encrypted channel. If the user is registered for the service and the client id, which has also been sent along with the user credentials, is recognised, then the server sends back a valid access token. Otherwise responds with a 401 Unhautorized.

From now on the application will only be using the access token for all requests until, eventually, the token expires. If that happens, the cycle repeats. Please note that in this scenario the client does not need to (and probably should not) store the username and/or password on the local cache. The User Credentials pattern usually relies on long lived tokens so asking again for username and password is not a big deal (you could also opt for permanent, revokable tokens.)

Flask-Sentinel provides two endpoints: one for token creation which defaults to /oauth/token and is consumed by clients, and another for users and clients management, accessible at /oauth/management:

Note that the password is hashed and salted on the server, so no plain password is stored on either sides of the channel.

Only existing users and recognised clients will be provided an access token. A typical token request would be as follows:

$ curl -k -X POST -d \
  "client_id=9qFbZD4udTzFVYo0u5UzkZX9iuzbdcJDRAquTfRk&
   grant_type=password&
   username=jonas&
   password=pass" \
   <api_url>/oauth/token

And the response would be like so:

{
    "access_token": "NYODXSR8KalTPnWUib47t5E8Pi8mo4", 
    "token_type": "Bearer", 
    "refresh_token": "s6L6OPL2bnKSRSbgQM3g0wbFkJB4ML", 
    "scope": ""
}

The client can now use the access token to access protected API endpoints:

$ curl -k -H \
  "Authorization:Bearer NYODXSR8KalTPnWUib47t5E8Pi8mo4" \
  <api_url>/endpoint

200 OK

There are a number of configuration options of course, for example you can change the url of token and management endpoints, set token expiration, setup database connection, stuff like that. Redis is used to store active access tokens, allows for optimal performance.

While you can use Flask-Sentinel to extend an existing API, you might want to instance it as a stand-alone Flask application to optimize for scalability. You would end up with a distributed network of three different (micro)services: the OAuth2 server, the resouces API with protected endpoints as needed, and the Redis instance bridging the two. Check out the project page on GitHub for details.

Of course Flask-Sentinel integrates seamlessly with any Eve powered REST API. Check out the Eve-OAuth2 sample, a fork of the original Eve-Demo project with a couple protected endpoints and a static HTML page, also protected.

The project is very new and lacks a few little things, but I suspect it is already usable even at this stage. Enjoy!

If you want to get in touch, I am @nicolaiarocci on Twitter.

As a developer, I sometimes forget the power I yield. It’s easy to forget that, when something doesn’t work the way I’d like, I have the power to change it.

via Python and Flask Are Ridiculously Powerful.

Soprattutto ho rilevato una forte curiosità su MongoDB, un database non-relazionale verso il quale sembra prevalere un atteggiamento  di generale timidezza: “vorrei ma non oso”, insomma. Per quanto riguarda Flask direi che ormai, nel vasto firmamento dei micro web framework, è una stella che brilla di luce propria.

Per quanto riguarda le registrazioni video potete andare su YouTube o sulla pagina ufficiale di EuroPython (english track e italian track). Ammetto di essere più soddisfatto della versione inglese nella quale – complice anche l’esperienza italiana del giorno prima – credo di essere stato più sintetico ed efficace. Qui mi limito a proporvi le slide:

Ringraziamenti

Un immenso grazie ai ragazzi dello staff di EuroPython che veramente hanno fatto di tutto per rendere questa manifestazione un evento straordinario – e ci sono riusciti  (una settimana di talk su cinque tracce parallele, sprint, hands-on, corsi, cibo di ottima qualità e credo oltre 800 partecipanti).

Vi racconto un episodio giusto per darvi l’idea di quanto questi ragazzi, tutti volontari, si diano da fare e ci mettano passione vera. Nella sessione italiana ho ‘sforato’ (capita anche ai migliori, mi dicono!) e così mi son trovato a sorvolare su un certo numero di slide. Ebbene il mio talk manager e il suo assistente mi hanno proposto di loro iniziativa di tenere una sessione pomeridiana straordinaria per consentirmi di portare a termine la mia relazione. Non capita tutti i giorni, credetemi. Per mia fortuna gran parte delle persone che avevano assistito alla sessione mattutina sono poi tornate per quella del pomeriggio, altrimenti sai che figura!

Se siete pythonisti o vorreste diventarlo non perdetevi la prossima edizione di questo evento internazionale che, con tutta probabilità, si terrà di nuovo a Firenze l’anno prossimo.

Tutto ciò significa che l’installazione di Flask MimeRender su Windows, OSX e Linux è diventato più semplice:

Codice sorgente e istruzioni sono a vostra disposizione su GitHub, mentre per spiegazione approfondita ed esempio d’uso vi rimando al mio articolo precedente: Una REST API che adatta le sue risposte al MIME Media-Type delle richieste HTTP.

Una delle specifiche REST più importanti vuole che un servizio RESTful sia in grado di fornire dati in più formati, in modo tale da soddisfare il maggior numero possibile di utenti/applicazioni. Immaginiamo un servizio che fornisce i risultati delle partite del campionato di calcio. Supponiamo che arrivino tre richieste successive per lo stesso risultato: la prima potrebbe chiedere una risposta in formato XML, la seconda in JSON e la terza in HTML. Il  nostro servizio deve rispondere a tutte e tre le richieste, adattando il flusso di dati della risposta al formato di ognuna.

Nel mio caso la API che sto implementando supporta XML, JSON, HTML e testo puro. E’ scritta in Python (ma va!) e si appoggia all’eccellente Flask micro web framework. Per risolvere in maniera elegante il problema delle risposte multi-formato ho deciso di usare i decorator, una delle caratteristiche più interessanti di Python. Dopo un po’ di lavoro in proprio ho scoperto che qualcuno aveva già risolto il problema, per giunta con la stessa tecnica. MimeRender di Martin Blech è un’ottima soluzione, solo che è specifica per web.py (un altro web framework). La mia soluzione non disponeva di alcune opzioni interessanti che MimeRender include; ho deciso allora di scrivere un port di MimeRender per Flask, e di metterlo a disposizione del pubblico.

Istruzioni per l’uso

Prima di tutto è necessario fornire le funzioni da usare per il rendering, una per ogni formato che intendiamo supportare:

Quindi decoriamo la nostra funzione, definendo per lei la mappa delle funzioni di rendering:

Tutto qui! In caso di richiesta GET la funzione index restituisce un dizionario, il quale verrà reso da MimeRender come XML, JSON o quant’altro, a seconda del Content-Type specificato nella richiesta HTTP:

Su github trovate l’esempio completo nonché il codice sorgente del renderer, che potete scaricare liberamente.