Python-social-auth, verwendet in Japans größtem Ticketkauf- und -verkaufsservice "Ticket Camp" Dies ist eine Arbeitsnotiz beim Aktualisieren von 0.1.x auf 0.2.13.
Als Voraussetzung verwende ich es in Kombination mit Django 1.7.x und ich verwende social.apps.django_app.default anstelle von social.apps.django_app.me.
Normalerweise sollten Sie Djangos manage.py migrate ausführen, aber aus verschiedenen Gründen ist dies nicht möglich. Überprüfen Sie daher die Änderungen basierend auf SQL.
Liste verwandter Tabellen.
>SHOW TABLES LIKE 'social_auth_%';
+------------------------------------------+
| Tables_in_ticketcamp_dev (social_auth_%) |
+------------------------------------------+
| social_auth_association |
| social_auth_code |
| social_auth_nonce |
| social_auth_usersocialauth |
+------------------------------------------+
Das 0.1.x-Schema, das Sie derzeit verwenden.
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;
Das neueste Schema der Version 0.2.13.
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;
Mit Ausnahme des Unterschieds in der Indexschlüssel- und Spaltenreihenfolge
--- 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;
BaseStrategy.backend ist verschwundenBeim Upgrade auf 0.2 wurde Refactoring zur Vermeidung eines Zirkelverweises auf "Strategie" und "Backend" aufgenommen -edfca398eb84334baeba76ce424a2611), sodass Sie in der Pipeline nicht mehr wie "Strategy.backend" darauf verweisen können.
Damit
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 wie
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)
Behoben, wie es aussieht.
Vorläufig ging ich zu dem Punkt, an dem ich mich mit 0.2.13 als Mitglied registrieren und anmelden konnte, aber ich fürchte, ich kann es nicht in der Produktionsumgebung veröffentlichen, ohne ein wenig mehr Unit-Tests hinzuzufügen.
Recommended Posts