Twitter login via OAuth about pybossa

[teleyinex]

Have you seen BrowserID from Mozilla? It seems pretty interesting :)

[teleyinex]

@rgrp I've a running version of the Twitter OAuth authentication for PyBossa. However I do not like too much my code yet, as everything is in the 'account' blueprint. Any advise to refactor the code properly? I guess that the twitter object should be created in the core.py file, and exported via the flask.g proxy to the blueprint. What do you think?

[teleyinex]

@rgrp Maybe it is even better to move everything to utils.py, and import it only when needed. It is more like a helper function than anything else. What do you think?

[teleyinex]

@rgrp Now I've a running branch in my laptop that works well with Twitter. It checks if it is the first time that you use Twitter to log in and in that case it asks you to provide an email.

While I was coding I realized that it will be interesting to store the user_id from Twitter in the DB. I've been reading sqlalchemy-migrations and I've a changeset (tested in SQLite and PostgreSQL) that adds an extra column (twitter_user_id) to the User table. The script is stored in the repository pybossa/pybossa/migrations and I was thinking if you like this approach or if you prefer to recreate the DB completely as there are not too many users or projects using PyBossa yet.

Another possible solution is to use the flags and category columns from the User table (these columns are already defined) in the following manner:

• category: for specifying that the user used Twitter, Facebook or whatever to create the account
• flags: for storing the user_id associated to the Twitter, Facebook or whatever provided that we will use for authenticate the user.

This last solution is the most simple one, so I would vote for it :) The only problem is that category and flags are Integer columns, so we should use an array to map the categories. Something like: Twitter -> 0, Facebook ->1, Google ->2, etc.

What do you think? In any case learning sqlalchemy-migrate has been very useful :D

[teleyinex]

Hi again :D After reading your post about sqlalchemy I'm now more confident that we should use SQL migrations. Today I've been reading the new tool created by the same guy that created SQLAlchemy to do the migrations: alembic. It is really easy, and removes the duplication problem reported by you in your post. Thus, I'll use alembic as it is pretty simple and keeps the model not too verbose. The migrations are going to be used only for migrations, nothing else.