Profile cover photo
Profile photo
Ib Lundgren
225 followers -
Single threaded with faulty memory
Single threaded with faulty memory

225 followers
About
Ib's posts

Post has attachment
If you would like to help oauthlib by doing code reviews please ping https://github.com/idan/oauthlib/issues/294 and I will ask you to review  pull requests I make in the future. 

Your help will be much appreciated!

Post has attachment
Excellent in depth episode on database systems, where they came from, are now, and are moving in the future from Software Engineering Radio.

Covers what is wrong with the traditional SQL architecture, why MapReduce is not the answer to everything, as well as outlines numerous interesting projects like Column DBs and Graph DBs and where they fit in. But most interestingly of all was probably the advances made in memory data bases over traditional disk focused DBs.

Hey everyone!

Finally have some time after a long crunch of course assignments and other pressing duties and am happy to say that the loooong overdue release of OAuthLib 0.6.1 is pushed to PyPI. This includes numerous small updates so check out the README. It might contain some fairly raw features related to revocation so please let me know if you run into anything!

That was OAuthlib, going to catch up on requests-oauthlib (cc Cory Benfield)  on Wednesday :)

Post has attachment

Post has attachment
#Vim s gq command, saving my sanity on a daily basis.

Post has shared content
Deciding on OAuth token vs API keys?

If you want to protect your API so only authorized clients may access it then the common approach is to use API keys and basic authentication. This is useful when the API does not protect user data but generic data such as sport league results, tv listings, etc. Here any client with a valid API key is authorized to access any data and authenticates using said key.

When your API protects user data (tweets, pictures, etc.) you might want to restrict the clients so that they can only access user data after said user have given them permission. This is where OAuth comes in. OAuth gives a token which is essentially a temporary API key bound to only one users data. Often you want to restrict this even further by only allowing access to the users pictures. That is what OAuth scopes are used for. Note here that the user allowing a client access to its data is the "Authorization" of OAuth. 

To make sure the token sent from a client is from a valid client authentication is needed as well but optional in OAuth 2. Confidential (authenticated) clients in OAuth 2 usually authenticate using Basic Auth (but could be using pub/priv keys or any other method as well).

However if you will have mobile clients you are running into the issue of reliable authentication as there is no technically safe way to hide a secret on a device out of your control. OAuth 2 (Implicit grant) makes a compromise by not requiring authentication here but instead limiting the time a token might be used.

Deciding on OAuth token vs API keys?

If you want to protect your API so only authorized clients may access it then the common approach is to use API keys and basic authentication. This is useful when the API does not protect user data but generic data such as sport league results, tv listings, etc. Here any client with a valid API key is authorized to access any data and authenticates using said key.

When your API protects user data (tweets, pictures, etc.) you might want to restrict the clients so that they can only access user data after said user have given them permission. This is where OAuth comes in. OAuth gives a token which is essentially a temporary API key bound to only one users data. Often you want to restrict this even further by only allowing access to the users pictures. That is what OAuth scopes are used for. Note here that the user allowing a client access to its data is the "Authorization" of OAuth. 

To make sure the token sent from a client is from a valid client authentication is needed as well but optional in OAuth 2. Confidential (authenticated) clients in OAuth 2 usually authenticate using Basic Auth (but could be using pub/priv keys or any other method as well).

However if you will have mobile clients you are running into the issue of reliable authentication as there is no technically safe way to hide a secret on a device out of your control. OAuth 2 (Implicit grant) makes a compromise by not requiring authentication here but instead limiting the time a token might be used.

Post has attachment
OAuthLib 0.6 is out!

0.6 features a major interface change on the provider side where the method contract on all endpoints, OAuth 1 & 2, change to a three-tuple down from a four-tuple. Redirect URI is now placed in headers as Location where it belongs.

Other changes include a number of clean ups in tests and can proudly say we now reach 97% coverage :) With more edge case tests and clean ups on the horizon.

Next up on the to do list is Token Revocation, this spec is still a draft but fairly small in scope and doubt much changes will be made before RFC.

cc #python #oauth

Post has attachment
Just bought this excellent bootstrap template and will dissect it into jinja2 chunks over the next few days :)

Post has attachment
Have a wish/suggestion for what to include in the #requests-oauthlib docs? I'd love a comment here or at https://github.com/requests/requests-oauthlib/issues/48.

It could be anything that needs improving (change structure, less/more detail etc) or something you want added. A specific guide/tutorial or example on how to use provider X.

A few obvious sections are missing related to the non web application flow, if you know providers other than Google offering these, let me know!
Wait while more posts are being loaded