Assign UUID to users and use that when communicating with client app

RESOLVED FIXED

Status

P1
major
RESOLVED FIXED
8 years ago
2 years ago

People

(Reporter: wenzel, Assigned: ozten)

Tracking

Dependency tree / graph

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
If we use the SSO nickname when talking to a client app, people can never change it without fear of username hijacking.

So we should assing a UUID to users that is only used in communication with the client apps, and never changes. No-one will see this except SSO <-> client app.
(Reporter)

Updated

8 years ago
Depends on: 580290
(Reporter)

Updated

8 years ago
Priority: -- → P1
(Assignee)

Comment 1

8 years ago
I've played with

1) Sub-classing django.contrib.auth.models.User with SSOUser and putting a new property sso_uuid on this model.

2) Using the Django User.get_profile support to create a UserProfile model which has a property sso_uuid.

#1 is a slightly better choice from a performance perspective, as the UUID would be handy in the auth_users table. The downside is that all the code that access the User would need to access the SSOUser instead. I messed with implementing an Auth Backend and ran into some issues. It also introduces some magic, which is bad. All of this is probably premature optimization and so I'm writing then with solution #2 instead. We'll be caching these objects, so a second query is not a big deal. If we add more "profile" information, we'll already be setup with the get_profile pattern.
Assignee: nobody → ozten.bugs
Depends on: 583797
(Assignee)

Comment 2

8 years ago
Created attachment 464651 [details] [diff] [review]
First stab, patch for bug583797 second attempt tree

Note: This patch will only apply on top of the 583797_2 branch of Bug#583797.

Patch can also be revied at http://github.com/mozilla/secret-squirrel/commit/583fe4bf1003fe0dd2d232c7b946d3e9b952748f
Attachment #464651 - Flags: review?(fwenzel)
(Reporter)

Comment 3

8 years ago
Comment on attachment 464651 [details] [diff] [review]
First stab, patch for bug583797 second attempt tree

I like that, good job! Now we only need to use it in the cas_provider app as opposed to the username (when sending "yes\nusername").
Attachment #464651 - Flags: review?(fwenzel) → review+
(Assignee)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.