I need split my current Django application into two sites.
Site A will contain the public facing site which would contain all the static pages and the registration system.
The other site — Site B — is the site for registered users. They can also log-in to application site through Site B.
If I'm not mistaken, I can use django.contrib.sites framework to accomplish the task of having multiple sites but can have a common authetication/registration backend?
How can I accomplish this?
Thanks.
Django's django.contrib.sites framework is nice if both sites are running under the same server and access the same database. If you have a distributed application (different sites on different hosts or different sites on different databases), you can resort to single sign-on solutions.
I use OpenID with a custom provider to centralize logins between apps running on different databases. Other solutions include CAS (provider and consumer).
For this case, you would have 2 settings.py files called settings_A.py and settings_B.py which specify from settings import *
A would have SITE=1 and B would have SITE=B. you can then set these files in your apache configs by setting the environment variable for each virtual host DJANGO_SETTINGS_MODULE=settings_A and DJANGO_SETTINGS_MODULE=settings_B
Then you set up the contrib.sites app with your 2 domain names bound to the appropriate site ID, and your flatpages will be able to be bound to either or both sites.
Lastly, in settings_A.py settings_B.py you either specify seperate root urlconfs or you use the use settings.SITE in your urlconfs to enable and disable groups of urls for each site.
Hope this helps
EDIT: To clarify: as long as you use the same database and SECRET_KEY between both sites, you can use the same user accounts between them too. If the sites are of the form example.com and private.example.com then setting SESSION_COOKIE_DOMAIN to .example.com will allow the session to carry over between both sites.
You could use (external) LDAP authentication for both sites. You would need a LDAP server somewhere reachable for both sites. I never used this and I don't know how well it integrates with Django auth though. See http://packages.python.org/django-auth-ldap/
Related
I am newbie to Django, but I know how to create a simple application in python-Django how to add new page , how to link it into url file etc.
Now what I am trying to do, I am trying to create a very simple webapp where On the landing page I will have a login link.
When the user clicks on this link it should go to george washington universities authentication window and then I can enter my university's credential and it should authenticate and come back to a page stating ** Login Successful**
I have gone through many tutorials, but all looks very confusing.
I have installed xmlsec1, pysaml2, djangosaml2 modules but even after that I was clueless what to do next. I never felt so much clueless like I am feeling for this authentication module.
It will be great if anyone can guide me with the process.
You didn't say what web server you were using but, on Apache, I'd recommend you use the mod_shib Apache module in conjunction with the Django authentication middleware.
In broad strokes, you are going to let Apache/mod_shib do the SAML heavy lifting and interact with the IdP and you are going to let Django manage users for you. You are going to connect the two by using a piece of Django authentication middleware that authenticates users using the REMOTE_USER environment variable to communicate between Apache and the Django app.
So, first setup Django using Django authentication as described in the Django documentation. Validate that you can create a user using the admin tools and that you can login and establish a session using the Django authentication methods.
Once you have simple, local login working, install the RemoteUser middleware and validate that, by setting the REMOTE_USER environment variable, you can cause your Django app to log a user in (you can do all this testing using the development server locally on your development machine).
Once you have demonstrated that you can log a user in by having the REMOTE_USER environment set, you need to install the Apache shibboleth module, mod_shib and use it to protect the root of your application.
Assuming your application is located at /mysite the config in your virtualhost section would include:
<Location /mysite>
ShibRequestSetting redirectToSSL 443
AuthType shibboleth
ShibRequestSetting requireSession 1
Require valid-user
</Location>
That configuration will tell apache that the /mysite path requires mod_shib to get involved and forces the communication over ssl/tls.
I will not go through all the configuration steps needed to install and configure shibboleth but, basically, you want to set your application default (shibboleth2.xml file) with REMOTE_USER=eppn (if you want to use another attribute like eptid you would specify that); this tells the module which attribute to stuff in the REMOTE_USER environment variable. Again, the shib doc is pretty clear here so I won't go into detail about how to redirect to your university IdP but, basically, you will create an entry in your Sessions section of the form:
<SSO entityID="https://idp.testshib.org/idp/shibboleth">
Where you would substitute your IdP location for the testshib URL shown above.
Note that we are setting REMOTE_USER to the eppn value and that that value will be interpreted by the Django auth middleware as the user's username; you will need to create Django users with usernames that are the same as their eppn for this to work. You can also allow Django to auto-provision new accounts if, for instance, you deem IdP authentication sufficient evidence to create a new user account but, with auto-provisioning, only the minimal bits get setup; you would still need to go into that account and set first name, last name, phone, etc.
The net effect is that, whenever an unauthenticated user tries to visit a location under /mysite, they will be redirected to your university IdP, they will logon there and be redirected back. The mod_shib module (in conjunction with the shibd daemon running in the background) will handle the attribute unpacking and the session state with the IdP and will set the eppn value in the REMOTE _USER environment variable. Assuming that your Django application was setup correctly with apache, it will be invoked and the RemoteUser middleware will use the eppn value set in the REMOTE_USER environment variable to lookup the user with that username in the authentication database. If it finds a user, it will complete the Django login process (i.e. set the user object in the request, set the session state, etc.)
One more thing. To talk to you university IdP and have it release attributes to your application (i.e. eppn), you will need to do three things:
Import their IdP metadata
Export your SP metadata and have your university identity folks import it
Get your university identity team to release eppn to you
Just be aware that those three steps can be a challenge and may take non-trivial time and homework.
One more one more thing: I would recommend verifying the SAML setup separate from your Django app/middleware integration. Using the simplest mechanism you are comfortable with (simple wsgi app, php script, whatever) create a page that will simply dump the REMOTE_USER environment variable when browsed then protect that first. Once you have that page redirecting to your IdP and dumping the correct eppn in REMOTE_USER on return, then you can move on to the Django bits.
I am developing a back-end for a webpage using Django Rest Framework. The webpage will be public, and it will only fetch information from this service. Thus, I have to deploy both service and webpage.
Since the webpage is public access (without any type of login) I can avoid having to set up the SSL stuff. However, by default, the DRF comes with the browsable API and the login field. I know I can remove the browsable API, but is it enough?
For instance, the configurations I would have would be:
(removing the BrowsableAPIRenderer)
'DEFAULT_RENDERER_CLASSES': ( 'rest_framework.renderers.JSONRenderer',
'rest_framework.renderers.JSONPRenderer',
'rest_framework_csv.renderers.CSVRenderer', )
and:
CORS_ORIGIN_ALLOW_ALL = True
CORS_ALLOW_METHODS = (
'GET',
'HEAD',
'OPTIONS',
)
I am using https://github.com/ottoyiu/django-cors-headers for the CORS stuff.
Would this be enough to avoid unwanted login atempts? Is there any specific way to disable this option?
What 'DEFAULT_PERMISSION_CLASSES' shoul I use?
Best regards and thanks for any help!
If you have a login, but you don't have SSL, then your users are vulnerable to packet sniffing of credentials on many wifi and ethernet networks. Such a vulnerability can be trivially exploited with the Firesheep firefox plugin. Due to users' habit of reusing passwords, you could end up compromising their security to a more critical website. This is very unfortunate. It isn't entirely your problem if users reuse their password, but SSL should be a base layer of protection to your users.
While it is possible to use Django templates with Django Rest Framework (DRF) as the backend, you are not limited to using Django for your front-end. Consider AngularJS with DRF. Anyways, there is a significant learning curve for AngularJS, but you needn't limit yourself to having Django supply your front-end.
As far as removing the DRF BrowsableAPIRenderer, you will get some protection from "security through obscurity", but you really need to lock down your APIs through a proper permission model as an attacker can easily look at traffic generated by your front-end to your back-end and then manipulate the requests to your back-end. So, discoverability of your interface by an adversary will not be significantly reduced through getting rid of BrowsableAPIRenderer. It will only obscure back-end resources that your front-end isn't currently using and it will also make your life as a front-end dev a little more painful.
For DEFAULT_PERMISSION_CLASSES, take a gander at DRF permissions documentation. If you only have two user groups - logged in/authenticate and not logged in, then IsAuthenticatedOrReadOnly is a good place to start. If you start to have per-model permission bifurcation for different user groups, then
DjangoModelPermissions is a good place to dig into.
I am creating a web application that will support several domains. For example, if my app were named www.webapp.com, I'd also have numerous customers mapping their domains to my site via DNS CNAME mappings, i.e. webapp.yourdomain.com CNAME www.webapp.com and foo.anotherdomain.com CNAME www.webapp.com, etc...
I want users to authenticate against my app via Google or Facebook (OAuth 2.0) - without me (or the domain owners) having to create a separate Google/Facebook app per mapped domain. Ideally, I would have the base domain act as a broker and redirect to the appropriate mapped domain when responding to the callback url. For example, a user visiting webapp.yourdomain.com/accounts/facebook/login would authenticate against Facebook with a callback url going to www.webapp.com/accounts/facebook/login/callback. When processing the request, I could find the appropriate context, and redirect to webapp.yourdomain.com/accounts/facebook/login/callback where the real authentication would take place (and domain-specific auth cookies would be set).
So, is this doable in django-allauth? How much hacking would it require? Or, is there another social authentication solution for Django that would be easier to implement this in?
You should use Django sites framework together with django-allauth.
Consumer keys, tokens make use of the Django sites framework. This is
especially helpful for larger multi-domain projects, but also allows
for for easy switching between a development (localhost) and
production setup without messing with your settings and database.
Just configure each social app in the admin backend.
I have a web application written in raw python and hosted on apache using mod_python. I am building another web application which is django based and will be hosted on same server using mod_wsgi.
Now, the scenerio is such that user will login from the web page which is using mod_python and a link will send him to my application which will be using mod_wsgi. My question is how can I maintain session? I need the same authentication to work for my application.
Thanks in advance.
If you're using django with mod_wsgi and a raw python page which only serve a link to django application, you don't need to maintain session on both page. When user click on first link and reach the django application, just check session there.
Django have session_db which use memcache. More information can be found here:
Django Sessions
SSO across web applications is poorly supported. One thing you can look at is:
http://www.openfusion.com.au/labs/mod_auth_tkt/
What you can do is really going to depend though on what authentication database you are currently using in the mod_python application and how you are remembering that someone is logged in. If you can provide that information, may be able to suggest other things.
Conceptually: store a cookie using your raw python web page that you process in a "welcome" view or custom middleware class in Django, and insert them into the sessions db. This is basically what hungnv suggests.
The most ridiculous way to do this would be to figure out how Django deals with sessions and session cookies, insert the correct row into Django's session database from your raw python app, and then custom-set the session cookie using Django's auth functions.
If you multiple subdomains e.g.:
sub1.domain_name.com
sub2.domain_name.com
Is there a way to have a user be able to log into both of these without issues and double login issue?
The platform is Python, Django.
Without information regarding what platform you are using, it is difficult to say. If you use cookies to store authentication information, and you are using subdomains as you describe, then you can force the cookie to be issued for the highest level domain, e.g. domain_name.com.
This will be accessable by both sub1 and sub2, and they could each use that for their authentication.
EDIT:
In the settings.py for each application running under the subdomains, you need to put
SESSION_COOKIE_DOMAIN = ".domain_name.com" as per the django docs
Yes. Just set the cookie on the domain ".domain_name.com" and the cookie will be available to sub1.domain_name.com, and sub2.domain_name.com.
As long as you maintain your session information on both domains, you should be fine.
This is a very common practice, and is why you can log into your Google Account at http://www.google.com/ and still be logged in at http://mail.google.com.