Re: Is there a package that enables one Django project to authenticate via a second Django project?

[David Rashty]

That's exactly what I was thinking, but I need to test it.  Thanks!



On Tue, Jun 30, 2020 at 12:54 PM Julio Cojom 
wrote:

> What about using DRF with token login?
>
>
>
> El jue., 25 jun. 2020 a las 13:26, Dave R () escribió:
>
>> I keep running into this problem and started working on a custom
>> solution... but before I spend hours on this, I want to confirm that such a
>> package/solution doesn't already exist.
>>
>> I was working on a large project last year that involved a single set of
>> users and many small applications.  I made each application a Django app
>> and had them all tied together in one database.  There was only one
>> database dependency between the applications: the User table.
>>
>> This became almost impossible to maintain for  multiple reasons:
>> * I had two apps that required different values in settings.py
>> * The test suite took forever to run
>> * One of the apps was developed originally using Postgres and I had to
>> spend hours hacking through code getting it to work with MySQL
>> * I had to share my entire code base to employ freelancers
>> * I had to deprecate one of the apps and this became a project in itself
>> (i.e., remove references in settings.py, dropping database tables, etc.)
>>
>> Next time I'm in this situation, I'd like to develop each application as
>> a separate Django project and have them authenticate (via OpenID Connect)
>> to a project dedicated to this (e.g., accounts.mysite.com).
>>
>> Has anyone seen an out-of-the-box solution for this?  The question is
>> very open-ended.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/0050a73c-fc46-449b-b087-a9f99508fadeo%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/TJQ_2Kx4O2U/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAHRQUHmRr_PFJpGA2sq%2B7bp4ci0pGo4es%2BxMP_CNdwM-NyTgwg%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALGYj_1q2bsEeXOhY9MONh%3DU6sMjtxyrxFG0TFDCnB%3DHQ9JOUA%40mail.gmail.com.

Re: Is there a package that enables one Django project to authenticate via a second Django project?

[Julio Cojom]

What about using DRF with token login?



El jue., 25 jun. 2020 a las 13:26, Dave R () escribió:

> I keep running into this problem and started working on a custom
> solution... but before I spend hours on this, I want to confirm that such a
> package/solution doesn't already exist.
>
> I was working on a large project last year that involved a single set of
> users and many small applications.  I made each application a Django app
> and had them all tied together in one database.  There was only one
> database dependency between the applications: the User table.
>
> This became almost impossible to maintain for  multiple reasons:
> * I had two apps that required different values in settings.py
> * The test suite took forever to run
> * One of the apps was developed originally using Postgres and I had to
> spend hours hacking through code getting it to work with MySQL
> * I had to share my entire code base to employ freelancers
> * I had to deprecate one of the apps and this became a project in itself
> (i.e., remove references in settings.py, dropping database tables, etc.)
>
> Next time I'm in this situation, I'd like to develop each application as a
> separate Django project and have them authenticate (via OpenID Connect) to
> a project dedicated to this (e.g., accounts.mysite.com).
>
> Has anyone seen an out-of-the-box solution for this?  The question is very
> open-ended.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/0050a73c-fc46-449b-b087-a9f99508fadeo%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAHRQUHmRr_PFJpGA2sq%2B7bp4ci0pGo4es%2BxMP_CNdwM-NyTgwg%40mail.gmail.com.

Re: Is there a package that enables one Django project to authenticate via a second Django project?

[David Rashty]

Thanks!

1. Yes.  djangito_server and djangito_client are regular Django apps that
are optimized to work together but can be used separately.  However, I
haven't specifically tested it using djangito_server with social_django.
I'll add "testing with social_django" as an item on the github issues list.
2. I looked at social_django and allauth, but didn't use them for a few
reasons.  The biggest is that I wanted to pull foreign key data in addition
to regular User data.  (djangito_client assumes that nested JSON
represents foreign key data.)  Also, I just didn't see enough value in
these 3rd party packages to create another dependency for djangito.  I did
leverage django-oauth-toolkit on the server side, however.   If there is
something I'm missing, please let me know.
3. 90% of the plumbing is there to support this.  I'll add it as an
enhancement in github issues.

In general, there are 4 advantages to using djangito vs other solutions:
1) It works out of the box
2) It handles foreign key fields on the User table
3) The server pushes changes to the user data to all the related
djangito_client applications
4) client data can be automatically merged into djangito_server.  (Note:
This isn't implemented yet.)  So if you have two projects with separate
user data, you can merge them all together to have a single source of
truth.  I'll probably add this as a button on the Django admin page.


On Tue, Jun 30, 2020 at 4:00 AM Andréas Kühne 
wrote:

> Hi,
>
> I saw your other post - great work with the oauth server and client apps.
> I think the solution looks very promising.
>
> I like the way you can configure everything. A few questions though:
> 1. Would it be possible to use another SSO package to login to the
> Djangito server? We currently use social_django to do the login which the
> client fixes.
> 2. Why not base it on other already existing products (like social_django)
> and not need to add your own code for everything?
> 3. Because it's based on oauth it should be possible to authenticate with
> an angular app for example - or?
>
> Regards,
>
> Andréas
>
>
> Den mån 29 juni 2020 kl 11:29 skrev David Rashty :
>
>> Got it.  Thanks for following up.
>>
>> I ended up rolling out my own solution based on django-oauth-toolkit:
>> https://github.com/pandichef/djangito
>>
>>
>> I'd love to get some feedback if you get a chance.  Thanks!
>>
>>
>>
>> On Mon, Jun 29, 2020 at 5:10 AM Andréas Kühne 
>> wrote:
>>
>>> The remote user functionality is still valid - however it is rarely
>>> used. I heard about it myself from one of the Django fellows - who are
>>> responsible for handling ticket triage on the django project itself. He
>>> said exactly what you are saying - that there isn't that much information
>>> about it and that the usage is not wide spread. However for your use case I
>>> would look into it?
>>>
>>> Regards,
>>>
>>> Andréas
>>>
>>>
>>> Den tors 25 juni 2020 kl 22:52 skrev Dave R :
>>>
 Is REMOTE_USER a technology that's still used?  Aside from the one page
 of documentation, I don't see a lot of other references to it on Stack
 Overflow, etc.

 In my implementation, the client authenticates to the server, pulls the
 latest-and-greatest user data, then saves it on the client database.

 Philosophically, I guess it's a personal preference.  But, as a startup
 person, I tend to build a lot of throwaway apps that I don't want
 cluttering up the core tried-and-tested apps.

 On Thursday, June 25, 2020 at 3:55:40 PM UTC-4 andrea...@hypercode.se
 wrote:

> First of all - why separate the django apps into various projects?
> That seems a bit strange because you are depending on one user account and
> one database? There isn't really any benefit of doing it like that - why
> not use a single django project?
>
> But on the other hand - if you want to continue doing it like that -
> what I would do is setup a "user" project - that only handles the users.
> Then you can use the remote user functionality of django in the other
> projects. That way you have the user object centralized and all of the
> projects can use the user interface from the remote user.
>
> https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/
>
> The reason I wouldn't use open id connect is because you still need a
> local user object for each project in that case.
>
> Regards,
>
> Andréas
>
>
> Den tors 25 juni 2020 kl 21:26 skrev Dave R :
>
>> I keep running into this problem and started working on a custom
>> solution... but before I spend hours on this, I want to confirm that 
>> such a
>> package/solution doesn't already exist.
>>
>> I was working on a large project last year that involved a single set
>> of users and many small applications.  I made each application a Django 
>> app
>> and had them all tied together in one database.  There was 

Re: Is there a package that enables one Django project to authenticate via a second Django project?

[Andréas Kühne]

Hi,

I saw your other post - great work with the oauth server and client apps. I
think the solution looks very promising.

I like the way you can configure everything. A few questions though:
1. Would it be possible to use another SSO package to login to the Djangito
server? We currently use social_django to do the login which the client
fixes.
2. Why not base it on other already existing products (like social_django)
and not need to add your own code for everything?
3. Because it's based on oauth it should be possible to authenticate with
an angular app for example - or?

Regards,

Andréas


Den mån 29 juni 2020 kl 11:29 skrev David Rashty :

> Got it.  Thanks for following up.
>
> I ended up rolling out my own solution based on django-oauth-toolkit:
> https://github.com/pandichef/djangito
>
>
> I'd love to get some feedback if you get a chance.  Thanks!
>
>
>
> On Mon, Jun 29, 2020 at 5:10 AM Andréas Kühne 
> wrote:
>
>> The remote user functionality is still valid - however it is rarely used.
>> I heard about it myself from one of the Django fellows - who are
>> responsible for handling ticket triage on the django project itself. He
>> said exactly what you are saying - that there isn't that much information
>> about it and that the usage is not wide spread. However for your use case I
>> would look into it?
>>
>> Regards,
>>
>> Andréas
>>
>>
>> Den tors 25 juni 2020 kl 22:52 skrev Dave R :
>>
>>> Is REMOTE_USER a technology that's still used?  Aside from the one page
>>> of documentation, I don't see a lot of other references to it on Stack
>>> Overflow, etc.
>>>
>>> In my implementation, the client authenticates to the server, pulls the
>>> latest-and-greatest user data, then saves it on the client database.
>>>
>>> Philosophically, I guess it's a personal preference.  But, as a startup
>>> person, I tend to build a lot of throwaway apps that I don't want
>>> cluttering up the core tried-and-tested apps.
>>>
>>> On Thursday, June 25, 2020 at 3:55:40 PM UTC-4 andrea...@hypercode.se
>>> wrote:
>>>
 First of all - why separate the django apps into various projects? That
 seems a bit strange because you are depending on one user account and one
 database? There isn't really any benefit of doing it like that - why not
 use a single django project?

 But on the other hand - if you want to continue doing it like that -
 what I would do is setup a "user" project - that only handles the users.
 Then you can use the remote user functionality of django in the other
 projects. That way you have the user object centralized and all of the
 projects can use the user interface from the remote user.

 https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/

 The reason I wouldn't use open id connect is because you still need a
 local user object for each project in that case.

 Regards,

 Andréas


 Den tors 25 juni 2020 kl 21:26 skrev Dave R :

> I keep running into this problem and started working on a custom
> solution... but before I spend hours on this, I want to confirm that such 
> a
> package/solution doesn't already exist.
>
> I was working on a large project last year that involved a single set
> of users and many small applications.  I made each application a Django 
> app
> and had them all tied together in one database.  There was only one
> database dependency between the applications: the User table.
>
> This became almost impossible to maintain for  multiple reasons:
> * I had two apps that required different values in settings.py
> * The test suite took forever to run
> * One of the apps was developed originally using Postgres and I had to
> spend hours hacking through code getting it to work with MySQL
> * I had to share my entire code base to employ freelancers
> * I had to deprecate one of the apps and this became a project in
> itself (i.e., remove references in settings.py, dropping database tables,
> etc.)
>
> Next time I'm in this situation, I'd like to develop each application
> as a separate Django project and have them authenticate (via OpenID
> Connect) to a project dedicated to this (e.g., accounts.mysite.com).
>
> Has anyone seen an out-of-the-box solution for this?  The question is
> very open-ended.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/0050a73c-fc46-449b-b087-a9f99508fadeo%40googlegroups.com
> 
> .
>
 --
>>> You received this 

Re: Is there a package that enables one Django project to authenticate via a second Django project?

[David Rashty]

Got it.  Thanks for following up.

I ended up rolling out my own solution based on django-oauth-toolkit:
https://github.com/pandichef/djangito


I'd love to get some feedback if you get a chance.  Thanks!



On Mon, Jun 29, 2020 at 5:10 AM Andréas Kühne 
wrote:

> The remote user functionality is still valid - however it is rarely used.
> I heard about it myself from one of the Django fellows - who are
> responsible for handling ticket triage on the django project itself. He
> said exactly what you are saying - that there isn't that much information
> about it and that the usage is not wide spread. However for your use case I
> would look into it?
>
> Regards,
>
> Andréas
>
>
> Den tors 25 juni 2020 kl 22:52 skrev Dave R :
>
>> Is REMOTE_USER a technology that's still used?  Aside from the one page
>> of documentation, I don't see a lot of other references to it on Stack
>> Overflow, etc.
>>
>> In my implementation, the client authenticates to the server, pulls the
>> latest-and-greatest user data, then saves it on the client database.
>>
>> Philosophically, I guess it's a personal preference.  But, as a startup
>> person, I tend to build a lot of throwaway apps that I don't want
>> cluttering up the core tried-and-tested apps.
>>
>> On Thursday, June 25, 2020 at 3:55:40 PM UTC-4 andrea...@hypercode.se
>> wrote:
>>
>>> First of all - why separate the django apps into various projects? That
>>> seems a bit strange because you are depending on one user account and one
>>> database? There isn't really any benefit of doing it like that - why not
>>> use a single django project?
>>>
>>> But on the other hand - if you want to continue doing it like that -
>>> what I would do is setup a "user" project - that only handles the users.
>>> Then you can use the remote user functionality of django in the other
>>> projects. That way you have the user object centralized and all of the
>>> projects can use the user interface from the remote user.
>>>
>>> https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/
>>>
>>> The reason I wouldn't use open id connect is because you still need a
>>> local user object for each project in that case.
>>>
>>> Regards,
>>>
>>> Andréas
>>>
>>>
>>> Den tors 25 juni 2020 kl 21:26 skrev Dave R :
>>>
 I keep running into this problem and started working on a custom
 solution... but before I spend hours on this, I want to confirm that such a
 package/solution doesn't already exist.

 I was working on a large project last year that involved a single set
 of users and many small applications.  I made each application a Django app
 and had them all tied together in one database.  There was only one
 database dependency between the applications: the User table.

 This became almost impossible to maintain for  multiple reasons:
 * I had two apps that required different values in settings.py
 * The test suite took forever to run
 * One of the apps was developed originally using Postgres and I had to
 spend hours hacking through code getting it to work with MySQL
 * I had to share my entire code base to employ freelancers
 * I had to deprecate one of the apps and this became a project in
 itself (i.e., remove references in settings.py, dropping database tables,
 etc.)

 Next time I'm in this situation, I'd like to develop each application
 as a separate Django project and have them authenticate (via OpenID
 Connect) to a project dedicated to this (e.g., accounts.mysite.com).

 Has anyone seen an out-of-the-box solution for this?  The question is
 very open-ended.

 --
 You received this message because you are subscribed to the Google
 Groups "Django users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-users...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-users/0050a73c-fc46-449b-b087-a9f99508fadeo%40googlegroups.com
 
 .

>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/30afa521-a35d-4ea3-b8d8-ec8cc3f297acn%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-users/TJQ_2Kx4O2U/unsubscribe.
> To unsubscribe from this 

Re: Is there a package that enables one Django project to authenticate via a second Django project?

[Andréas Kühne]

The remote user functionality is still valid - however it is rarely used. I
heard about it myself from one of the Django fellows - who are responsible
for handling ticket triage on the django project itself. He said
exactly what you are saying - that there isn't that much information about
it and that the usage is not wide spread. However for your use case I would
look into it?

Regards,

Andréas


Den tors 25 juni 2020 kl 22:52 skrev Dave R :

> Is REMOTE_USER a technology that's still used?  Aside from the one page of
> documentation, I don't see a lot of other references to it on Stack
> Overflow, etc.
>
> In my implementation, the client authenticates to the server, pulls the
> latest-and-greatest user data, then saves it on the client database.
>
> Philosophically, I guess it's a personal preference.  But, as a startup
> person, I tend to build a lot of throwaway apps that I don't want
> cluttering up the core tried-and-tested apps.
>
> On Thursday, June 25, 2020 at 3:55:40 PM UTC-4 andrea...@hypercode.se
> wrote:
>
>> First of all - why separate the django apps into various projects? That
>> seems a bit strange because you are depending on one user account and one
>> database? There isn't really any benefit of doing it like that - why not
>> use a single django project?
>>
>> But on the other hand - if you want to continue doing it like that - what
>> I would do is setup a "user" project - that only handles the users. Then
>> you can use the remote user functionality of django in the other projects.
>> That way you have the user object centralized and all of the projects can
>> use the user interface from the remote user.
>>
>> https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/
>>
>> The reason I wouldn't use open id connect is because you still need a
>> local user object for each project in that case.
>>
>> Regards,
>>
>> Andréas
>>
>>
>> Den tors 25 juni 2020 kl 21:26 skrev Dave R :
>>
>>> I keep running into this problem and started working on a custom
>>> solution... but before I spend hours on this, I want to confirm that such a
>>> package/solution doesn't already exist.
>>>
>>> I was working on a large project last year that involved a single set of
>>> users and many small applications.  I made each application a Django app
>>> and had them all tied together in one database.  There was only one
>>> database dependency between the applications: the User table.
>>>
>>> This became almost impossible to maintain for  multiple reasons:
>>> * I had two apps that required different values in settings.py
>>> * The test suite took forever to run
>>> * One of the apps was developed originally using Postgres and I had to
>>> spend hours hacking through code getting it to work with MySQL
>>> * I had to share my entire code base to employ freelancers
>>> * I had to deprecate one of the apps and this became a project in itself
>>> (i.e., remove references in settings.py, dropping database tables, etc.)
>>>
>>> Next time I'm in this situation, I'd like to develop each application as
>>> a separate Django project and have them authenticate (via OpenID Connect)
>>> to a project dedicated to this (e.g., accounts.mysite.com).
>>>
>>> Has anyone seen an out-of-the-box solution for this?  The question is
>>> very open-ended.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-users/0050a73c-fc46-449b-b087-a9f99508fadeo%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/30afa521-a35d-4ea3-b8d8-ec8cc3f297acn%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK4qSCeL%2BUmUJuC1wHsVt4UDQjRKG%2B1tyNMgiTrRxGJ2orJZgQ%40mail.gmail.com.

Re: Is there a package that enables one Django project to authenticate via a second Django project?

[Dave R]

Is REMOTE_USER a technology that's still used?  Aside from the one page of 
documentation, I don't see a lot of other references to it on Stack 
Overflow, etc.

In my implementation, the client authenticates to the server, pulls the 
latest-and-greatest user data, then saves it on the client database.

Philosophically, I guess it's a personal preference.  But, as a startup 
person, I tend to build a lot of throwaway apps that I don't want 
cluttering up the core tried-and-tested apps.

On Thursday, June 25, 2020 at 3:55:40 PM UTC-4 andrea...@hypercode.se wrote:

> First of all - why separate the django apps into various projects? That 
> seems a bit strange because you are depending on one user account and one 
> database? There isn't really any benefit of doing it like that - why not 
> use a single django project?
>
> But on the other hand - if you want to continue doing it like that - what 
> I would do is setup a "user" project - that only handles the users. Then 
> you can use the remote user functionality of django in the other projects. 
> That way you have the user object centralized and all of the projects can 
> use the user interface from the remote user.
>
> https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/
>
> The reason I wouldn't use open id connect is because you still need a 
> local user object for each project in that case. 
>
> Regards,
>
> Andréas
>
>
> Den tors 25 juni 2020 kl 21:26 skrev Dave R :
>
>> I keep running into this problem and started working on a custom 
>> solution... but before I spend hours on this, I want to confirm that such a 
>> package/solution doesn't already exist.
>>
>> I was working on a large project last year that involved a single set of 
>> users and many small applications.  I made each application a Django app 
>> and had them all tied together in one database.  There was only one 
>> database dependency between the applications: the User table.
>>
>> This became almost impossible to maintain for  multiple reasons:
>> * I had two apps that required different values in settings.py
>> * The test suite took forever to run
>> * One of the apps was developed originally using Postgres and I had to 
>> spend hours hacking through code getting it to work with MySQL
>> * I had to share my entire code base to employ freelancers
>> * I had to deprecate one of the apps and this became a project in itself 
>> (i.e., remove references in settings.py, dropping database tables, etc.)
>>
>> Next time I'm in this situation, I'd like to develop each application as 
>> a separate Django project and have them authenticate (via OpenID Connect) 
>> to a project dedicated to this (e.g., accounts.mysite.com).
>>
>> Has anyone seen an out-of-the-box solution for this?  The question is 
>> very open-ended.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/0050a73c-fc46-449b-b087-a9f99508fadeo%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/30afa521-a35d-4ea3-b8d8-ec8cc3f297acn%40googlegroups.com.

Re: Is there a package that enables one Django project to authenticate via a second Django project?

[Andréas Kühne]

First of all - why separate the django apps into various projects? That
seems a bit strange because you are depending on one user account and one
database? There isn't really any benefit of doing it like that - why not
use a single django project?

But on the other hand - if you want to continue doing it like that - what I
would do is setup a "user" project - that only handles the users. Then you
can use the remote user functionality of django in the other projects. That
way you have the user object centralized and all of the projects can use
the user interface from the remote user.

https://docs.djangoproject.com/en/3.0/howto/auth-remote-user/

The reason I wouldn't use open id connect is because you still need a local
user object for each project in that case.

Regards,

Andréas


Den tors 25 juni 2020 kl 21:26 skrev Dave R :

> I keep running into this problem and started working on a custom
> solution... but before I spend hours on this, I want to confirm that such a
> package/solution doesn't already exist.
>
> I was working on a large project last year that involved a single set of
> users and many small applications.  I made each application a Django app
> and had them all tied together in one database.  There was only one
> database dependency between the applications: the User table.
>
> This became almost impossible to maintain for  multiple reasons:
> * I had two apps that required different values in settings.py
> * The test suite took forever to run
> * One of the apps was developed originally using Postgres and I had to
> spend hours hacking through code getting it to work with MySQL
> * I had to share my entire code base to employ freelancers
> * I had to deprecate one of the apps and this became a project in itself
> (i.e., remove references in settings.py, dropping database tables, etc.)
>
> Next time I'm in this situation, I'd like to develop each application as a
> separate Django project and have them authenticate (via OpenID Connect) to
> a project dedicated to this (e.g., accounts.mysite.com).
>
> Has anyone seen an out-of-the-box solution for this?  The question is very
> open-ended.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/0050a73c-fc46-449b-b087-a9f99508fadeo%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAK4qSCckHVc_Uk0nw25Dk2nXCvfuOnaf1dfxQO9kD1PqMu_P%3Dg%40mail.gmail.com.