I'm trying to integrate my MediaWiki site with some custom Python web applications. I have complete control over the MediaWiki server and am free to change the authentication plugin if needed. For the time being, I would like all users to login via a screen on the MediaWiki page (or at least they should believe they are, the whole process should be transparent to them).
In general, I would prefer not to completely write my own authentication code, but I don't mind doing some minor adapting.
I'm looking for some advice from people who have done something like this before, my questions are:
I know absolutely nothing about LDAP, but it seems rather commonly supported with various plugins for MediaWiki and Python. Is it best to have a central LDAP server, and then force all applications to authenticate here?
As compared to the above, what are the downsides of just reading from the wiki database, and comparing to see if the shared-secret from the user's cookie match, and then assuming they are logged in?
Is it advisable to use openID for a situation like this? What are some of the downsides?
This might seem obvious but have you seen the LDAP Authentication extension? We used it (with some modifications) and it works well.
You can also use in combination with e.g. Lockdown.
So my (limited) answers to your questions are:
Yes (I can't think why you would not want it in one place).
One downside is if users move groups / authentication. They need manually to delete their cookies, which can cause headaches for people supporting the wiki.
Sorry, don't know that one.
Hope this limited answer helps.
Related
Given Google's latest move towards OpenID Connect and the lack of extensive documentation on GAE's Users API, wanted to ask the community if it's a good idea to continue to use Users API
Should we expect this to become deprecated in the near future and look to move away from this service as soon as possible?
Much appreciated!!
Also, just for clarity sake I'm referring to: https://cloud.google.com/appengine/docs/python/users/
When Google deprecates some service it doesn't do that overnight, ample time (many months, typically over a year) comes between the official announcement and when the service discontinuation becomes effective, with detailed plans, guidelines and procedures for migrations to whichever alternative solutions are available and recommended at that time.
Jumping ahead to a solution without a valid reason may actually be worse. For example the Users Api has been around long before OpenID 2.0, which is now deprecated :)
The functionality of the Users API is still very much valid for many apps (and even various other pieces of Google infrastructure) which do not actually need the additional features of OpenID Connect. The API and the service is simple, mature and stable. In other words I don't think there is a valid reason for Google to deprecate the API, at least not at this time.
So I wouldn't worry about it yet, at least not for apps already implemented - if it ain't broken don't fix it :)
For new apps, especially if it's unclear if they would need at some point some functionality not presently provided by the Users API, it might make more sense to go directly for another authentication method.
I am working on developing two systems:
A system that will constantly retrieve economic data from a 3rd party data feed and push it into a MySQL DB (using sqlalchemy)
A server that will allow anyone to query the data in the db over a JSON AJAX API (similar to Yelp or Yahoo API for example)
I have two main questions:
Which Python framework should I use in 2)? Pyramid is my first choice, but if you strongly suggest against it or in favor of something else like Django or Pylons I am definitely wiling to consider it.
Should I develop the two system separately? Or should 1) be a part of 2), running within the framework (using crontab or celery for example)?
Depends on what stage you are at, I would suggest to develop 2 systems because the load to pull data from 3rd party and the load to handle the API would be different. You can scale them into a different types of nodes if you want.
Django-Tastypie (https://github.com/toastdriven/django-tastypie) is not bad, it supports all JSON, XML and YAML. Also you can add OAuth easily. Though, Django itself maybe a bit heavy for your needs at this time.
You might want to check out web2py's new functionality for easily generating RESTful API's, particularly its parse_as_rest and smart_query functions. You might also consider using web2py's database abstraction layer to handle #1.
If you need any help, ask on the mailing list.
I agree with Anthony, you should look at Web2Py. It is very easy to get started, very low learning cure and easy to deploy on many systems including Linux, Windows and Amazon.
So far I have found nothing that Web2Py can not do. But more importantly it does things how you would think they should be done, so if you are not sure, very often a guess is good enough and it just works. If you do get stuck, it has by far the best and most up to date documentation for any Python Web Framework.
Even with all it's great features, easy use and up to date documentation, you will also find that the web2py user group on Google, is like having a paid for help desk staffed 24 hours a day. Most questions are answered with a couple minutes and Massimo (The original creator of Web2Py) goes out of his way not only to help, but to implement new ideas, suggestions and bug fixes within days of them being raised in the group.
I'm developing an advertising site and want to use web services for the requests. I mean, a publisher site will put a JavaScript snippet and it will pull a banner through a REST GET.
Is the django-piston framework mature enough to implement this functionality?
I've been looking into finding the "best" Django REST package and came across this table, which is useful:
http://www.djangopackages.com/grids/g/api/
At this point (mid-2011) Django-Tastypie is the clear winner for number of authors, updated codebase, documentation, and overall activity.
EDIT, Jan.2012: I think the two leading contenders are now Django-Tastypie, and also, Django-REST-framework. The latter has a really useful feature of web-browsable APIs, which I've yet to see in other packages.
I am currently using it and it's good enough for my needs, which are fairly simple (mostly just an easy way to set up a read-only API for model data). I do have a couple of criticisms:
It doesn't seem that jespern, the code's creator, is doing much in response to issues posted to bitbucket. Possibly an unfair criticism, and activity in the django-piston Google Group. Still it's frustrating to post an issue and encounter zero response whatsoever.
It appears there are some inconsistencies or errors in the coding. For example, this issue that I posted. (I may pursue it further in the group).
I can't answer "is it mature enough." We are still evaluating our options ourselves.
However, you might want to check out these:
http://github.com/toastdriven/django-tastypie -- perhaps an up and coming competitor to piston.
http://ericholscher.com/blog/2009/nov/11/large-problems-django-mostly-solved-rest-api/
Django is certainly mature enough. It's powering more than a dozen high-profile sites in production. Piston on the other hand, I wouldn't know, except for bitbucket.org. I don't know of any other "high-profile" sites that use it. It doesn't sound like you need a complex framework on top of Django just to handle REST. You could easily implement a RESTful service on top of Django without using any other specific library.
After much research, I've come up with a list of what I think might be the best way of putting together a Python based social network/cms, but have some questions about how some of these components fit together.
Before I ask about the particular components, here are some of the key features of the site to be built:
a modern almost desktop-like gui
future ability to host an advanced html5 sub-application (ex.http://www.lucidchart.com)
high scalability both for functionality and user load
user ability to password protect and permission manage content on per item/group basis
typical social network features
ability to build a scaled down mobile version in the future
Here's the list of tools I'm considering using:
Google App Engine
Python
Django
Pinax
Pyjamas
wxPython
And the questions:
Google App Engine -- this is an attempt to cut to the chase as many pieces of the puzzle seem to be in place.
Question: Am I limiting my options with this choice? Example: datastore not being relational? Should I wait
for SQL support under the Business version?
Python -- I considered 'drupal' at first, but in the end decided that being dependent on modules that may or
may not exist tomorrow + limitations of its templating system are a no-no. Learning its API, too, would be useless elsewhere
whereas Python seems like a swiss army knife of languages -- good for almost anything.
Question: v.2.5.2 is required by GAE, but python.org recommends 2.5.5. Which do I install?
Django -- v.0.96 is built into GAE. You seem to be able to upgrade it.
Questions: Any reason not to upgrade to the latest version? Ways to get around the lack of HTML5 support?
Pinax (http://pinaxproject.com) Rides on top of Django and appears to provide most of the social network functionality
anyone would want.
Question: Reasons NOT to use it? Alternatives?
Pyjamas and wxPython -- this is the part that gets a little confusing. The basic idea behind these is the ability
to build a GUI. I've considered Silverlight and Flash, before the GAE/Python route, but a few working versions of
HTML5 apps convinced me that enough of it ALREADY runs on the latest batch of browsers to chose the HTML5/Javascript
route instead.
Question: How do I extend/supplement Python/Django to build an app-like HTML5 interface? Are Pyjamas and wxPython
the way to go? Or should I change my thinking completely?
Answers to some/any of these questions would be of great help. Please excuse my ignorance if any of this doesn't make much sense.
My last venture into web programming was a decent sized LAMP website some 5-6 years ago. On the desktop side of things,
my programming experience boils down to very high level scripting languages that I keep on learning to accomplish very specific
tasks :)
As someone who has deployed a Django site to GAE, I can tell you that you are not going to reach the ideal solution. Django on GAE misses some of the best aspects of Django because the ORM doesn't work right. The best compromise may be to use Django-nonrel to add the features back in.
This introduces it's own problems though: because of the large number of files and memory used by a Django app you're code will be unloaded from memory quickly after the app becomes idle. That means that visitors will frequently hit an approximately 6 second delay on the first page view after the site's code has been unloaded from memory while GAE uncompresses the zipped modules. Once your site is busy this won't be a problem, but while your site is still young and unknown it will cause the appearance of performance problems. :-(
Second, I've also worked for a company that built a custom CMS and can tell you that the first 80% is pretty easy, especially with modern frameworks. However, the rest can be quite challenging. For example, user roles and custom content types are two challenging aspects. Therefore strongly consider standing on the backs of giants and finding a CMS or CMS framework that almost perfectly meets your needs and then extend it to do that extra bit you need.
So, that said, answering your points:
Yes, you're limiting your options but that may be OK. Most developers are more comfortable with the relational model than the nosql model. Therefore more open source software is built with it in mind. Also, GAE is a closed source platform which is also a deterrent to open source developers. App Engine Oil is a CMS framework that may suit you well and is optimized for App Engine. Also look at web2py which has support for GAE.
I've found myself to be extremely productive with Python. I used to write a lot of PHP now I find it ugly. That said, think about the total line count of code you'll have to write. If you can make Drupal work with high quality pre-made modules you may find yourself only needing 1/10th of the code. By the way, the trick with Drupal is to mainly use only high quality modules. Look at the history, make sure not to use development versions. Try to contact the authors on IRC. I'm not saying you should use Drupal but it is possible to have a reliable site with it (for example, whitehouse.gov)
You're in the classic GAE/Django problem. If you use 0.96 you get great performance but you miss a lot of the great 1.0+ features and you don't get the ORM and all of it's benefits. If you use a newer version of Django you get the performance/memory problems mentioned above.
I'm about to investigate pinax for my company. I've done a very cursor glance at it. I don't know if it has good support for non relational model backends. You'll probably need to look at django-nonrel. However know that you're going to be investing in relatively untried solutions here. A small percentage of Django users use Pinax and an even smaller percentage, if any, use it on a nonrelational backend. Therefore you're going to be in the highly experimental scenario you mentioned in point 2 above.
I can't offer personal experience on it. I've investigated pyjamas a few times. However I like writing HTML CSS and JS. I like to have control. I like progressive enhancement and knowing what users will see if they don't have the full capabilities. Also, I think any new app that doesn't explicitly address mobile clients is implicitly shooting themself in the foot. As many as 15% of Internet users only use the Internet via their smart phone. What kind of experience will they get with pyjamas?
You didn't mention this, but one thing I consider when choosing a platform is vendor lockin and portability. If you develop your solution for GAE and find that you're not able to do what you want, will you be able to port it to another solution elsewhere? How much work will it take? If you code heavily for GAE or make commitments to its architecture, you're stuck with it or with rewriting to move. Using Django or Web2py can help mitigate this.
That said, the big benefit of Python GAE is that you get to be very productive, see your results instantly, get hosting for free while your site is small and get excellent scalability. These are not small things. There is great value there.
I want basic authentication for a very minimal site, all I personally need is a single superuser. While hard-coding a password and username in one of my source files is awfully tempting, especially since I'm hosting the site on my own server, I feel I'm breaking the law of the internets and I should just use a database (I'm using sqlite for blog posts and such). Which would be the easiest to setup, in terms of time and effort, out of OpenID or AuthKit (repoze just scares me.. it feels like too much overhead for what I'm trying to achieve), or should I roll my own?
Why I brought up OpenID is, it might just solve my spam problem (I'm currently using Akismet), to just require all commentors to login with an OpenID. I have absolutely no idea how to go about integrating OpenID with my WSGI application though (it's probably dead simple, I've never actually looked into it yet).
also look at repose.who
http://static.repoze.org/whodocs/
AuthKit includes a built-in OpenID module, if that helps.
The AuthKit cookbook includes a simple example here... http://wiki.pylonshq.com/display/authkitcookbook/OpenID+Passurl
That said, if you only need a single login (so there's no complex user management going on), why not use Apache's built-in authentication features (AuthUserFile .htpasswd together with Require valid-user)?
Opid is a very small and simple to use WSGI OpenID app: python-opid
You can adapt this.
http://code.activestate.com/recipes/302378/
Or, better, adapt this.
http://devel.almad.net/trac/django-http-digest/
This is quite nice.