Python-social-auth used in Japan's largest ticket sales service "TicketCamp" It is a work memo when updating from 0.1.x to 0.2.13.
As a premise, I'm using it in combination with Django 1.7.x and using social.apps.django_app.default
instead of social.apps.django_app.me
.
Normally, you should run Django's manage.py migrate
, but for various reasons you can't do that, so check the changes based on SQL.
List of related tables.
>SHOW TABLES LIKE 'social_auth_%';
+------------------------------------------+
| Tables_in_ticketcamp_dev (social_auth_%) |
+------------------------------------------+
| social_auth_association |
| social_auth_code |
| social_auth_nonce |
| social_auth_usersocialauth |
+------------------------------------------+
The 0.1.x schema you are currently using.
CREATE TABLE `social_auth_association` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`server_url` varchar(255) NOT NULL,
`handle` varchar(255) NOT NULL,
`secret` varchar(255) NOT NULL,
`issued` int(11) NOT NULL,
`lifetime` int(11) NOT NULL,
`assoc_type` varchar(64) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `social_auth_code` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`email` varchar(75) NOT NULL,
`code` varchar(32) NOT NULL,
`verified` tinyint(1) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `email` (`email`,`code`),
KEY `social_auth_code_09bb5fb3` (`code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `social_auth_nonce` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`server_url` varchar(255) NOT NULL,
`timestamp` int(11) NOT NULL,
`salt` varchar(40) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `social_auth_usersocialauth` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`provider` varchar(32) NOT NULL,
`uid` varchar(255) NOT NULL,
`extra_data` longtext NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `provider` (`provider`,`uid`),
KEY `social_auth_usersocialauth_6340c63c` (`user_id`),
CONSTRAINT `user_id_refs_id_c8898d4c` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
The latest version 0.2.13 schema.
CREATE TABLE `social_auth_association` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`server_url` varchar(255) NOT NULL,
`handle` varchar(255) NOT NULL,
`secret` varchar(255) NOT NULL,
`issued` int(11) NOT NULL,
`lifetime` int(11) NOT NULL,
`assoc_type` varchar(64) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `social_auth_code` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`email` varchar(254) NOT NULL,
`code` varchar(32) NOT NULL,
`verified` tinyint(1) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `social_auth_code_email_801b2d02_uniq` (`email`,`code`),
KEY `social_auth_code_c1336794` (`code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `social_auth_nonce` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`server_url` varchar(255) NOT NULL,
`timestamp` int(11) NOT NULL,
`salt` varchar(65) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `social_auth_nonce_server_url_f6284463_uniq` (`server_url`,`timestamp`,`salt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `social_auth_usersocialauth` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`provider` varchar(32) NOT NULL,
`uid` varchar(255) NOT NULL,
`extra_data` longtext NOT NULL,
`user_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `social_auth_usersocialauth_provider_e6b5e668_uniq` (`provider`,`uid`),
KEY `social_auth_usersocialauth_user_id_17d28448_fk_auth_user_id` (`user_id`),
CONSTRAINT `social_auth_usersocialauth_user_id_17d28448_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Except for the difference in index key and column order,
--- 0.1.sql 2015-12-12 06:36:39.164810101 +0000
+++ 0.2.sql 2015-12-12 06:36:18.612810595 +0000
@@ -11,7 +11,7 @@
CREATE TABLE `social_auth_code` (
`id` int(11) NOT NULL AUTO_INCREMENT,
- `email` varchar(75) NOT NULL,
+ `email` varchar(254) NOT NULL,
`code` varchar(32) NOT NULL,
`verified` tinyint(1) NOT NULL,
PRIMARY KEY (`id`),
@@ -23,8 +23,9 @@
`id` int(11) NOT NULL AUTO_INCREMENT,
`server_url` varchar(255) NOT NULL,
`timestamp` int(11) NOT NULL,
- `salt` varchar(40) NOT NULL,
- PRIMARY KEY (`id`)
+ `salt` varchar(65) NOT NULL,
+ PRIMARY KEY (`id`),
+ UNIQUE KEY `social_auth_nonce_server_url_f6284463_uniq` (`server_url`,`timestamp`,`salt`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE `social_auth_usersocialauth` (
@@ -38,4 +39,3 @@
KEY `social_auth_usersocialauth_6340c63c` (`user_id`),
CONSTRAINT `user_id_refs_id_c8898d4c` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
--Changes in Django 1.8 gives ʻemaila maximum of 254. --The maximum number of
salt is 65 due to the change of
python-social-authby [this Issue](https://github.com/omab/python-social-auth/issues/141). --The unique constraint of
(server_url, timestamp, salt)is attached by [this Issue](https://github.com/omab/python-social-auth/issues/490) of
python-social-auth`. ..
BaseStrategy.backend
property has disappearedWhen upgrading to 0.2, [refactoring to avoid circular references of strategy
and backend
was included](https://github.com/omab/python-social-auth/commit/7a21ae5626b73a6409f6f5c7ed58a1416adc55af#diff -edfca398eb84334baeba76ce424a2611), so you can no longer refer to it like strategy.backend
in the pipeline.
So
from django.shortcuts import redirect
from social.pipeline.partial import partial
@partial
def my_pipeline(strategy, user=None, *args, **kwargs):
if user:
return
return redirect('next_action', strategy.backend.name)
Code like
from django.shortcuts import redirect
from social.pipeline.partial import partial
@partial
def my_pipeline(strategy, user=None, *args, **kwargs):
if user:
return
backend = kwargs.get('backend')
if not backend:
return
return redirect('next_action', backend.name)
Fixed to look like.
For the time being, I went to the point where I could register and log in as a member with 0.2.13, but I'm afraid that I can't put it out in the production environment without adding a little more unit tests.
Recommended Posts