django-cookieless | Django without cookies - sessions and decorator
kandi X-RAY | django-cookieless Summary
kandi X-RAY | django-cookieless Summary
This package provides a sessions implementation and decorator class for views to allow for forms to maintain state without using cookies by posting the session id between forms, or via urls. Django requires cookies to maintain session, and hence for authorisation. This package is designed to cater for anonymous user session maintenance, without cookies. WARNING : There are security issues with this, since it is not possible to use CSRF protection without session Cookies to maintain a separate token from that passed via the URL or form posts. However there are cases when forms are used on a public site, where setting cookies is not desirable (`due to privacy legislation `_), since technically they are not required for anonymous users to respond to forms. So if used, may necessitate requesting permission to set cookies, from the user. Hence this package was devised to allow django to deliver multipage forms, without using cookies. To ameliorate the security implications, a whitelist of allowed domains, can be set in the configuration. Usage can also be restricted to a particular URL. As another safety measure, handling of GET requests can be turned off, so that the encrypted session id is not present in any URLs. Please NOTE: It is not advisable to use this package without some form of the above restrictions being in place. For the purposes of using both cookie based and cookieless sessions together, there is a custom cookieless_signal(sender=request, created) and a no_cookies flag when cookieless sessions are saved. Both cater for hooking up custom code for handling these less secure sessions. The package provides a decorator utility to turn off cookie setting for particular views (which also sets the csrf_exempt flag). The package also handles the case of session handling for anonymous users with cookies disabled in the browser. You can decorate views to prevent them setting cookies, whilst still retaining the use of Sessions. Usually this is easiest done in the urls.py of your core application …. from cookieless.decorators import no_cookies. >>> urlpatterns = [ … path(somewhere/index, no_cookies(views.home)), … re_path(r'^somewhere/page/(\d{1,6})$', no_cookies(views.page)), …]. Note that if a number of browser tabs are open on to a site with cookieless, they will each maintain a completely separate session, since without cookies the session is tied to the session posted from the pages accessed, not the client as a whole. In cases where this is not the desired behaviour, then it can be reduced by using URL rewriting to make any links to open other windows pass session across. However of course this also means that potentially a session can be shared across browsers, too.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Render the URL
- Checks if the given request is specific
- Encrypt a session
- Derive key from request
- Decorator to set cookies to None
- Render a hidden session
django-cookieless Key Features
django-cookieless Examples and Code Snippets
Community Discussions
Trending Discussions on django-cookieless
QUESTION
In oTree, two cookies are created:
sessionId
and csrf_token
.
I want to disable both; however, I don't know how to do that.
I know that when I use participant_label
in the URL, I can avoid the sessionId
-cookie. However, then I still have the csrf_token
-cookie.
Do you know how to unset it? I heard that django-cookieless should be a solution, but I don't know how to use that.
...ANSWER
Answered 2021-Jan-30 at 18:25Ok, it's a bit untrivial.
For injecting csrftoken
in Django (which oTree is based on) they use CsrfViewMiddleware
. So if it would be a normal Django project you would just delete CsrfViewMiddleware
from MIDDLWARE
param in your settings.py
. But unfortunately oTree usually does the things in a very peculiar way that can drive crazy most of the people and to do this you need a bit of work.
This work consists of two parts:
write your own middleware that will manually delete all the cookies from any request.
Manually delete
CsrfViewMiddleware
after your app starts. You may ask 'why the first part wouldn't be enough? Because apparently CsrfViewMiddleware kicks in after your middleware, and it will still inject a cookie even if you manually delete it. You may ask why you need (1) if we do (2) - I do not know the answer for sure, but I suspect that oTree in addition injects some other cookies (including csrf), so if you just delete CsrfViewMiddleware that's not enough (I can be wrong).
Anyway. Part 1. Writing your own middleware
- You create a python file in one of your apps, let's say
middle.py
. You write there something like:
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install django-cookieless
Rewriting the response automatically rather than use manual <% session_token %> <% session_url %>
Rewrite URLs to add session id for no_cookies decorated views (if False then all page navigation must be via form posts)
Use client ip and user agent to encrypt session key, to add some sort of CSRF protection given the standard CSRF has to be disabled without cookies.
If this list is populated then only hosts that are specifically whitelisted are allowed to post to the server. So any domains that the site is served over should be added to the list. However, if no referer is found, the session is reset, which will occur with a page reload. This helps protect against XSS attacks.
Further security option to not find and persist cookie based sessions as cookieless ones since these may be tied to a user or other data. Instead new sessions are created for tying to cookieless data. This reduces the risk of cookieless allowing capture of a user’s session - and hence privilege escalation attacks.
Further security option to only keep a session for accessing a specific URL
Delete any cookies that are found for a no_cookies decorated URL (could be ones set by other URLs)
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page