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 <rashtyda@gmail.com>:
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 <andreas.kuhne@hypercode.se> 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 <rashtyda@gmail.com>: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.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éasDen tors 25 juni 2020 kl 21:26 skrev Dave R <rash...@gmail.com>: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+unsubscribe@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 group and all its topics, send an email to django-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK4qSCeL%2BUmUJuC1wHsVt4UDQjRKG%2B1tyNMgiTrRxGJ2orJZgQ%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CALGYj_3qiT9CphZKBDDSqz0M0U4NCB-Yyo%2BAfr%3D7qT_tDA1QuA%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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAK4qSCdHoXhL5Wf1%3DYVudV7raXkn%3DrL8fK1zU%3D%3DO5t0MPoSTSQ%40mail.gmail.com.
No comments:
Post a Comment