Forgive me if the wording here is a bit odd. I have a fair amount of experience with python, but I'm pretty new to Django and still trying to get my sea legs.
I've inherited a PHP site from the former System admin at my new job, and I want to rework it into a django app to simplify/cleanup the code.
The PHP site is using .htaccess file with Pubcookie apache module for authentication (as well as some basic checks in the php code to ensure the user checks out against a database of authorized users, but that part i'm less concerned with), and looks like this:
AuthType SecureID
require valid-user
PubcookieAppID "name of the app"
In my apache configs, I have various pubcookie definitions.
LoadModule pubcookie_module /usr/lib/apache2/modules/mod_pubcookie.so
PubcookieGrantingCertFile /usr/local/pubcookie/keys/pubcookie_granting.cert
PubcookieSessionKeyFile /etc/ssl/private/akey.pem
PubcookieSessionCertFile /etc/ssl/certs/acert.pem
PubcookieLogin https://weblogin.domain.com/
PubcookieLoginMethod POST
PubcookieDomain .domain.com
PubcookieKeyDir /usr/local/pubcookie/keys/
PubcookieAuthTypeNames ADUserID null SecurID
My question is...How do I implement this sort of thing on the python end? I have looked at using RemoteUserMiddleware, or PersistentRemoteUserMiddleware.
But most of the information I have found for that doesn't go into great detail about how to actually point your app at the correct login page. The official documentation seems to stop at adding the middleware under middleware in the settings.py file in the django project.
It also bare's mentioning that the weblogin.domain.com is handled by another group that I don't have direct access to, and is not one of my servers so I can't really poke around there.
I realize this is...extremely broad, but any information that could point me in the right direction would be appreciated.
In an ideal scenario, I would like to be able to restrict different views to different authtypes, but I'd be happy to get anything working sensibly.
So, For what it's worth. The answer was to use pubcookie with apache as normal. then use RemoteUserMiddleware or PersistentRemoteeUserMiddleware as expected. As it turns out you don't have to handle any outside configuration for the middleware, it just imports whats shoved at it.
Finally the piece I was really missing, information from apache/pubcookie authentication can be accessed with request.META library from inside django code
Related
It's been a while since I last used Django for a project and there have been some really great advances in the core project and the ecosystem around it.
One of those is the mature API development libraries like django-rest-framework.
So far I'm loving it. But it seems that all the guides I've found are disabling the Django Admin when using Django Rest Framework.
The reasons I've seen given were essentially "We don't need it for anything" or "We aren't using sessions, which Admin uses, so it won't work, so we're not using it."
"Don't need it" is a valid reason.
But other than that, are there reasons that it's bad practice to keep the Django Admin enabled when the project is primarily used as an API?
For my purposes, I find it convenient to manage user permissions and as a simple way to code admin only functions for dealing with the underlying data.
note: I've considered whether this question is designed to elicit opinions, which is not appropriate on SO. I believe that the answers I'm asking for will be technical or security based reasons with fact or experience based reasoning.
Totally agree.
On my current project, users are getting and setting ALL data via django-rest-framework.
Like you, I find the admin site convenient to manage user permissions, permissions groups, writing emails, sms, mobile applications push and more.
More, all these models are being translated, and translation is set in THE ADMIN SITE !!!
So, if we need a new object with translation, we do not need a new app release (example in pic of a question).
objects translations are readable and clear.
Data is organized nicely with minimal effort.
Admin get cool skins (jet / grappelli etc etc)
Language activation works like a charm in the APIViews.
I have built my first Django App! It is built to help my business track inventory. As such, I would not like it to be publicly available.
Maybe someday I will set up multiple user accounts, etc, but for now I really just need a basic password gate to get it up and running.
Does anyone have any middleware that works for this? All the solutions that I am finding are pretty old and they do not seem to work with the latest version of Django.
If you just need a single username/password couple, handling it directly via HTTP authentication in your webserver configuration will be the easiest way to achieve this. The benefits of this approach are:
You can set it up in 5 minutes: example with nginx, example with apache
You don't have to write code you'll delete later
It will protect all your website, including static files, third-party apps, admin, etc.
I found an answer that worked for me posted here:
#login_required for multiple views
Make sure the LOGIN_REQUIRED_URLS_EXCEPTIONS path is correctly set to your login page.
I would like to have one users system (preferrably Django's) to rule both Django and Wordpress.
The use case is that Django is an application embedded inside a wordpress installation (via iframe or something similar). In order to use the Django, users must be authenticated, authentication in WordPress is not mandatory, but recommended (for posting comments and stuff like that).
In order to ease the usage of the site, I would like the same sign-up to apply for both the Django app and the WordPress installation. Sign-up might occur either via OAuth / FB authentication (lots of Django solutions for this), or via dedicated site users. While the signup process is most important, it would be nice if certain user fields would remain synced between the two worlds.
My thoughts on the matter:
Maybe there's an out-of-the-box solution (couldn't find any)
Create a full-fledged django app for syncing the two user models (wp_users and django's users) via one of the following options:
A master(django)-slave(wp) solution, where each change in Django changes info in the wp_users and other related tables and vice-versa (via Django periodically checking the DB or creating a WP plugin). Can be implemented either by putting both django and wp on the same (MySQL) db, using XML-RPC or some other anomination I didn't think of.
Same as above, but let WP be the master instead of Django (seems harder).
An external system to rule both models - maybe make OAuth / some other external authentication mandatory, and somehow sync the two models using this?
Has anyone encountered this situation before?
Any suggestions will be appreciated.
You should really try to work out some approach, revising your work when encountering problems afterwards.
Nevertheless imo Wordpress is kind of bordered. I wouldn't recommend making changes to both frameworks, but fixate on Django.
For example you could create a WordpressUser(User) and create a python script a crobjob, celery task or whatever you'll need to syncronize your databases. Meaning to say you should keep things strictly separated unless you have very good reasons not to (I can't think of any).
My Apache (mod_wsgi) Django app only lists the files of my website/project instead of the actual running website/application. My guess is that it's mod_wsgi that is the culprit but I'm not really sure. What are some of the causes of this?
Don't put your Django site code in a directory Apache can serve up. Right now if I knew the actual site host name, I could get down your Django settings file and get access to your database password information.
Anyway, ensure you have gone and set up a basic WSGI hello world program before you attempt to get Django working under mod_wsgi. In doing this, ensure you use the official mod_wsgi documentation and not some arbitrary persons blog post. As such, go read:
http://code.google.com/p/modwsgi/wiki/QuickInstallationGuide
http://code.google.com/p/modwsgi/wiki/QuickConfigurationGuide
Also go watch the video presentation at:
http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Conference_Presentations
as it steps you through basic configuration as well as what to do for Django. It covers all the basic things that people do wrong.
If you still can't get it to work, then heed the comments in:
http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Asking_Your_Questions
about useful information you should supply to any forum to help people solve your problem.
http://github.com/uswaretech/Django-Socialauth/tree/master/socialauth/
I'm a bit confused on how I should use this. Of course, I read the notes at the bottom but I'm a Django novice so I'll need a little hand holding.
The structure of this looks like a project structure since it contains a urls.py but I'm also aware that applications can also have that. It also has a manage.py which leads me to believe it's a project ( plus the subdirectories ).
So should I just be integrating portions of this into my existing project? This isn't an application, right?
The README also mentions grabbing API Keys. So if I want a standard interface where you click on a google/yahoo logo and it forwards itself via Javascript to the authentication page where you login if you already aren't logged in, kicks you back to your own page, would I need API keys?
Any other special tips are appreciated.
[We wrote this]
There are quite a few forks, which are ahead of us so you might want to use that.
If you just want openid, you dont need API Keys
If you want twitter/FB you definately need keys.
urls.py and manage.py are too show a demo app.
socialauth is the django app, which you can pull out.
I would use the fork from agiliq (same guys).
If you look at the commits in agiliq and uswaretech, you will see that the agiliq fork has more recent commits.
https://github.com/agiliq/Django-Socialauth/commits/master
https://github.com/uswaretech/Django-Socialauth/commits/master
And you could also use django-social-auth, which might seem to be another fork, but it's a completely different implementation.