Authentication integration: Difference between revisions

Line 3:

The OpenHatch website is comprised of a few pieces. There's the OpenHatch codebase in Django, but there's also this wiki and we are [[choosing a forum]]. I'd like logins to be integrated.

== ~~Strategy~~ ==

== Overview ==

Django code creates domain cookies within openhatch.org that contain the user's username and email address. The application (like the wiki) can read that information and verify it using HMAC-SHA1.

Only applications in *.openhatch.org can receive user data. HMAC-SHA1 is used to verify the authenticity of the data that is passed through. Th

== Details ==

When (e.g.) the wiki wants to get the OpenHatch username and email address corresponding to the current session, it

=== Application: redirect ===

Line 34:

The application should make its own "logged in" status expire at the end of the session.

== Known issues ==

There are some problems with this setup. Some security issues:

* Email addresses and usernames travel along the network unencrypted. (In practice, this is no worse than the status quo, since session IDs already do that.)

* Not all applications treat usernames as case-sensitive. This might allow an attacker to create a new username that is treated as equivalent to a different user, effectively stealing an account.

** We can fix this by constraining usernames on the Django side to be case-insensitively unique.

*** Right now, Django usernames [http://code.djangoproject.com/ticket/2273 seem to be case sensitive].

Some usability issues:

* The first time the user goes to the forum, the browser will redirect a few times. That'll be weird.

Missing features:

* If an account gets deleted within the OpenHatch Django app, we don't have a way to ask downstream applications to delete their account of the same name.

[[Category:Hacking_OpenHatch]]