Closed Bug 674635 Opened 13 years ago Closed 13 years ago

kuma-mdn: Switch from Mindtouch to Django for auth

Categories

(developer.mozilla.org Graveyard :: User management, task)

Product:
developer.mozilla.org Graveyard
Component:
User management
Platform:
x86
macOS
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: lorchard, Unassigned)

References

Details

(Keywords: qawanted, Whiteboard: u=user c=wiki p=2 pa=7)

Currently, registration and login on MDN is handled by Mindtouch. However, we can flip that around as part of an incremental switch-over to Kuma. The Mindtouch API exposes methods to create and edit account info, change passwords, and verify login credentials. So, we could run all of account management through the Django side of the site, rather than through the Mindtouch web front-end. What this will let us do are things like: * Make the new profile pages a part of the signup flow, and include password changes on the page instead of a link to Mindtouch. * Silently migrate Mindtouch account passwords to Django accounts. The password entered into a Django form for a successful login to Mindtouch can be used to update the password for the matching Django account. Here are some Mindtouch API doc links for future reference: http://developer.mindtouch.com/en/ref/MindTouch_API/POST%3Ausers http://developer.mindtouch.com/en/ref/MindTouch_API/POST%3Ausers%2F%2Fauthenticate http://developer.mindtouch.com/en/ref/MindTouch_API/PUT%3Ausers%2F%2F%7Buserid%7D http://developer.mindtouch.com/en/ref/MindTouch_API/PUT%3Ausers%2F%2F%7Buserid%7D%2F%2Fpassword
Whiteboard: u=administrator c=siteadmin p=4
Another thing I just thought of: Combine this bug with bug 672238 (site config changes without code push), and we might be a lot closer to merging the "kuma" and "mdn" branches. If Django is handling all the account management and login, then I think the last major differences between "kuma" and "mdn" branches are: 1) Whether the new wiki is turned on; and 2) Whether deki is consulted during login. So, with a bit more work (say p=3), we'll be able to switch the state of 1 & 2 in Django with the admin config enabled by bug 672238
Bumping up the points, just as a cue to break this up into sub-tasks if/when we decide to tackle it. This will involve things like: * Registration forms * Forgot password flow * Email verification Some of this comes with Django, but we'll have to at least get it wired up and tested.
Whiteboard: u=administrator c=siteadmin p=4 → u=administrator c=siteadmin p=5
actually all of that is *functional* now in kuma thanks to the SUMO code. kuma-stage only uses django for registration and login. my biggest concern is making DekiWiki use django for auth if we want to enable django auth before we fully cut over to django wiki.
(In reply to comment #3) > actually all of that is *functional* now in kuma thanks to the SUMO code. > kuma-stage only uses django for registration and login. So, what I'm talking about is making all of that functional and polished on the "mdn" branch, too. > my biggest concern is making DekiWiki use django for auth if we want to > enable django auth before we fully cut over to django wiki. That's what this bug is about. We can fully control Deki's auth and account management from Django via the API and cookies.
Depends on: 675830
Depends on: 675831
Depends on: 675833
Broke this down into separate bugs as requested by Les in comment #2. Even if we don't end up doing all of this, it would be nice to keep the discussions organized.
Whiteboard: u=administrator c=siteadmin p=5 → u=administrator c=siteadmin p=0
(In reply to comment #5) > Broke this down into separate bugs as requested by Les in comment #2. Even > if we don't end up doing all of this, it would be nice to keep the > discussions organized. FWIW: There's quite a bit more more breakdown to do in terms of sub-tasks than what I mentioned on #2. Need to sit down and do a bit of thinking to come up with all of them
Summary: Switch from Mindtouch to Django for handling registration and login → Switch from Mindtouch to Django for registration, login, and account management
(In reply to comment #6) > (In reply to comment #5) > > Broke this down into separate bugs as requested by Les in comment #2. Even > > if we don't end up doing all of this, it would be nice to keep the > > discussions organized. > > FWIW: There's quite a bit more more breakdown to do in terms of sub-tasks > than what I mentioned on #2. Need to sit down and do a bit of thinking to > come up with all of them No problem. Feel free to open bugs for sub-tasks as you see fit, or just let me know what they are and I can take care of it.
OH today in IRC: <sheppy> I presume we have plans to support BrowserID on MDN eventually? Adding this as a blocker to bug 675708. Once we've flipped auth control from Mindtouch to Django, we can then look at adding BrowserID support on the Django side.
Blocks: 675708
Blocks: 620576
Target Milestone: --- → 1.4
Whiteboard: u=administrator c=siteadmin p=0
Depends on: 692238, 692237, 692239
Depends on: 692235
Target Milestone: 1.4 → 1.5
Depends on: 696854
This is yeomans work. Thanks for improving all of this!
Target Milestone: 1.5 → 1.6
Using this bug for PR feedback.
Assignee: nobody → lcrouch
Whiteboard: u=user c=wiki p=2
Target Milestone: 1.6 → 1.7
Summary: Switch from Mindtouch to Django for registration, login, and account management → kuma-mdn: Switch from Mindtouch to Django for auth
Blocks: 702988
Depends on: 704170
whew. this is on stage9 now. we need to test everything related to users - register, login, logout, forgotten password, etc.
Assignee: lcrouch → mozbugs.retornam
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: qawanted
Resolution: --- → FIXED
Whiteboard: u=user c=wiki p=2 → u=user c=wiki p=2 pa=7
Blocks: 706239
Version: Kuma → unspecified
Component: Administration → User management
Assignee: mozbugs.retornam → nobody
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.