Single auth database for multiple (different) django projects

[DK]

Hi,

I need to develop several django projects (let's assume that there are highly different one from each other). The common thing is users/groups data. If a user register into one of this sites, he should be able to use this same account credentials for all other sites.

I really didn't find any obvious solution to this problem:

1) Keeping everything in one database (single django project) - not possible, every of a project is big enough to be worth keeping separate, also using something like SITES (not really an issue here)  would provide do keeping data of all separate projects in one big database, what will cause a problems with maintenance (backuping everything together, etc.)

2) Using django multiple database support -  this would be great to put auth models into seperate common database, but django does not officially support multidatabase foreign key relations - making this useless. Any model with relation to auth.User would not be supported this way (in my projects almost every thing is somehow conneted to the user so this is dead end for me).

3) Using several databases and keeping auth tables in sync by external tool - very, very error prone. Writing something that deals with coherency problem will be very difficult, and there also will be a delay between sync's of databases in several projects - not really acceptable - user data should be stored in one point.

4) Creating central authorization point with Profiles, and make custom django authorization module that would work exaclty like OpenID authorization. But this still do not solve problem of NOT having multiple accounts in several django projects (even connected to one central Profile).

Any idea?

[Shawn Milochik]

How about Celery & RabbitMQ?

Use Django's signaling functionality to kick off a Celery task, use
Celery to make it async and nearly real-time, then transfer the info
securely.

I recommend *not* allowing the data to be serialized in the RabbitMQ
message (for security & performance), but rather initiate a call to the
other servers via HTTPS or scp with the info, or prompting the other
servers to do a callback to the originating server via HTTPS or scp call
of their own.

Of course, there's no way to avoid race conditions because a person can
be logged into more than one of these apps and once and make changes
nearly simultaneously, but

[Cal Leeming [Simplicity Media Ltd]]

On Thu, Jun 16, 2011 at 1:26 PM, DK <cypr...@gmail.com> wrote:

Hi,

I need to develop several django projects (let's assume that there are highly different one from each other). The common thing is users/groups data. If a user register into one of this sites, he should be able to use this same account credentials for all other sites.

I'm going to reply based on the assumption that the different sites are kept within multiple code bases?

 

I really didn't find any obvious solution to this problem:

1) Keeping everything in one database (single django project) - not possible, every of a project is big enough to be worth keeping separate, also using something like SITES (not really an issue here)  would provide do keeping data of all separate projects in one big database, what will cause a problems with maintenance (backuping everything together, etc.).

Not a good idea, you could open yourself up to all sorts of race conditions, compatibility, and migration issues.

 

2) Using django multiple database support -  this would be great to put auth models into seperate common database, but django does not officially support multidatabase foreign key relations - making this useless. Any model with relation to auth.User would not be supported this way (in my projects almost every thing is somehow conneted to the user so this is dead end for me).

Same as above.

 

3) Using several databases and keeping auth tables in sync by external tool - very, very error prone. Writing something that deals with coherency problem will be very difficult, and there also will be a delay between sync's of databases in several projects - not really acceptable - user data should be stored in one point.

Noooooooooo.

 

4) Creating central authorization point with Profiles, and make custom django authorization module that would work exaclty like OpenID authorization. But this still do not solve problem of NOT having multiple accounts in several django projects (even connected to one central Profile).

Having a central authorization point is the way forward. I'm a bit confused by this comment though:

"But this still do not solve problem of NOT having multiple accounts in several django projects"

Could you explain what you mean?

Cal

 

Any idea?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/2m_lo5mn8sYJ.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.

[DK]

On Thursday, June 16, 2011 2:38:52 PM UTC+2, SleepyCal wrote:

Having a central authorization point is the way forward. I'm a bit confused by this comment though:

"But this still do not solve problem of NOT having multiple accounts in several django projects"

Could you explain what you mean?

As far as I know, using authorization like Google Account, Facebook or OpenID just makes that user has an auto generated account in Django connected with external account (for example Google Account). So still - you bypass only the fact of logging, but storing/editing user profile, some other additional data is complicated and involves using this auto-generated accounts in django.

I hope  you get my point.

[Cal Leeming [Simplicity Media Ltd]]

Okay. If you want to have multiple webapps authenticating off a single user base, then you will need to either:

• Expose a server side authentication system (basically your own mini network of OpenID)
• Merge all the sites into a single Django webapp.

If you have a look through the mailing list archives, you will see someone else who had a similar issue, and I explained to them how to properly handle "cross domain handoffs".

http://www.mail-archive.com/django...@googlegroups.com/msg120598.html

Let me know if this helps answer your question.

Cal

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/8qBkZkMn5E0J.