Django Oauth calls - python

I've got a site built in django that I need to make oauth2.0 requests to an external site to get the currently logged in user. Right now I'm just using a test token, however I have to actually register callbacks on my site now. How do I do this?

you must add oauth2 to the INSTALED_APPS list and add some settings constant to the settings.py of the project and append some urls on the main urls.py file of the project and ...
read the django-oauth2 doumentations.

Related

How to restrict website access? for whole domain site?

I have website django based, i need access control domain based like. I already established django own auth system and 2-auth system. I need for whole domain access control even for the static files.
If that possible only access code not username and password, and this need to be hard coded env or something like this.
Django version v4.0, Hosting Heroku
For file protection you can create the fast tiny view, which send files back.
url for this view you can wrap with permission_required
urlpatterns += [
path("media/", permission_required('users.can_download', login_url='/')(Download.as_view()), name="download"),
...
]
https://docs.djangoproject.com/en/4.0/topics/auth/default/#the-permission-required-decorator
Every moment you can revoke this permission from every user.

Django not showing group manage options in admin page

Recently, I deployed a Django web app. However, when I'm accessing the admin page, I'm not getting the expected interface to add or remove a user from a certain group:
At the of inspecting the page, I'm receiving the following messages:
any idea about how to handle these errros?
Thanks!
Content Security Policies are usually controlled via middleware like django-csp. All the admin control JavaScript files are included as static files, no external libraries should be loaded, they should be on the same domain.
In order for CSP to allow to load these files, you need to add script-src 'self' (it's an alias for same-origin). Look inside settings.py for CSP_SCRIPT_SRC keyword and append 'self' (single quotation marks are required).
Note: if CSP headers are added not by Django, but by reverse proxy, like nginx, then you should look and fix configuration settings there.

Sharing authenticated users between Django and django-rest-framework in the same project

I have a Django project that will ultimately consist of three apps. Two of which will be "normal" Django apps, the third is a djangorestframework app. I also plan on creating a desktop client for the project at some point.
I want the rest app to be the only entity communicating with the database. Hence I use requests to communicate with the rest endpoints from the views of the "normal" Django apps and I will do the same for the desktop client. I want all apps to be accessible only for authenticated users, so I'm using Django's authentication backend.
My question is how to pass on the authenticated user/session from the pure Django apps to the rest endpoints when using requests in the views.
I managed to authenticate on the rest API using request's HTTPBasicAuth, but that requires me to have the user's password at hand in plain text. Sure, I could create a technical user to do these requests. But that would also mean that each and every request would need to go through authentication first and that doesn't feel like the best approach.
I have tried to extract the session cookie from the request object that is provided to the views and pass it on through requests.get, but did not manage to put it into the requests.get call the right way.
As of now, using requests and the established sessions looks like my best bet, especially since that will be the way the desktop client will do things, too. So I'm currently looking for the right way to provide requests.get with the session cookie, but I'm certainly open for better solutions.
You should use tokens.
Basically any kind of authentication out of your django project should be managed with secure tokens.
And yes, authentication check should happen everytime you send a request. To make it faster, you can store tokens in memory. (You can use redis or maybe even load your db on memory or ... ) but this is the right and common way to it. Even django does this check everytime using it's builtin functions.
DRF docs recommended some few packages to manage these tokens:
DRF: Third party packages
I used knox for many projects and it's pretty good.
Basically to authenticate your users over all of your projects or microservices, you have to take the token from user, set it as header or ... for your request to the main database or authentication project.
Most of the apps use token in headers which you can simply add to all of your requests calls:
Requests docs: Custom Headers

How do i make djangoCMS urls to work with my django app urls?

I'm developing a django site and i have built all my templates and then decided to install djangoCMS to manage my content, so the problem is that my django url patterns don't seem to work with djangoCMS page generated paths and this is causing a serious problem with the placeholders in my template pages since they only show up on structure view when i navigate to a djangoCMS page generated path but when i access the same page with my own defined urls the placeholders are not visible in structure view of the page? what might be causing this problem?
You'll need to modify your existing apps to be compatible with CMS & then you can attach them to pages using the app hook attribute.
You can read the docs on creating app hooks here; http://docs.django-cms.org/en/latest/how_to/apphooks.html
Essentially you will create a cms_apps.py file in your applications which look something like this;
from cms.app_base import CMSApp
from cms.apphook_pool import apphook_pool
from django.utils.translation import ugettext_lazy as _
#apphook_pool.register
class MyApphook(CMSApp):
name = _("My Apphook")
def get_urls(self, page=None, language=None, **kwargs):
return ["myapp.urls"]
Once you've setup your app, you might want to create menus for it so that privileged users can perform admin tasks without leaving the frontend. There's info on that here; http://docs.django-cms.org/en/latest/how_to/apphooks.html#apphook-menus

Confusions on /account/ vs /admin/ views (any built in way to create these)

I have begun to implement authentication throughout my applications in Django and have done this quite successfully with the Django login_required decorator.
However, I notice that this will always reroute to the deafault login URL: /accounts/... which is non-existent for me. I have been doing all my authentication through /admin/...
I imagine that the two are for different purposes (one for the admin users and allow access to the admin console) however, I cannot find any views for the accounts version (vs. admin). My questions are thus as follows:
What is the difference between /accounts/... and /admin/... if they use the same user models?
Are these /accounts/... views built in/templateable? How does one turn them on? Or do I need to create each manually?
Unfortunately I have found the documentation on this topic to be rather confusing and as such any help would be greatly appreciated.
If you are not logged in, Django uses the LOGIN_URL to decide which url to redirect to. By default, this is set to '/accounts/login/'.
If you use a different login url, then you should update your LOGIN_URL setting.
The disadvantage of using the Django admin to log in users, is that non-staff members will not be able to log in using the Django admin.
Django comes with authentication views, including a login view. If you want to allow non-staff members to log in, you should enable it.
The '/accounts/' is just a url that out of best practices most people when handling authentication. There are no built in templates for accounts. the '/accounts/' is just a default placed.
To change the url to fit your applications url, go to your settings.py file and you can add a LOGIN_URL variable to specify which location for the authentication to redirect to. In your case it will look like this.
LOGIN_URL = '/admin'
This will redirect all unauthenticated requests to '/admin'

Categories

Resources