I would like to use Zend Framework 2 with Doctrine 2 and openLDAP. My goal is to create a persistence for my LDAP. How can I accomplish this in ZF2?
I noticed that we can get objects from LDAP with Zend\Ldap\Node.
Can anyone show me an example of how to make a search from a LDAP and convert the results into nodes and/or maybe into a Collection of Nodes?
I'd like to have objects to work on after the search.
Thanks
Well, this may come "a little" late, but just to give others pointers on how to do this. I have created a Module called SamLdapUser which runs its authentication against Ldap / AD. A sample configuration is provided.
The persistence layer (user-object in application) is created through a second Module. This Module hooks in to the getIdentity() function of the authentication Service and then queries the database for the user-object. If no object is existing, a new object will be created. You can check the source code for my module SamLdapUserObject, too.
Related
I'm developing a web application that doesn't need database. All data comes via REST.
My question is: Is possible to use a model class (extended from AppModel) to manage data from a RESTfull service?, How to do that?, Does CakePHP any way to mapping directly a RESTfull web service?.
I have researched and I have found the $useTable attribute (http://book.cakephp.org/2.0/en/models/model-attributes.html#usetable) but I'm not sure if exists another way to do this in a better way.
My first idea is implement my own functions in a Model and put $useTable to false.
Thank you.
There is no such functionality that ships with CakePHP, but it's relatively easy to implement it on your own.
Check out datasources, they sit between the model and the data, but can also be used standalone, ie you can use datasource instances directly, or indirectly through the model layer (find/save/delete calls are using the datasource CRUD methods).
Checkout https://github.com/nodesagency/CakePHP-Rest-Datasource for some inspiration.
Basically, I have two django servers (django v 1.2):
Server 1 has a bunch of models, local database, and remote database access to ModelA in Server 2.
Server 2 has ModelA
I want to use ModelA.objects.get() and django ORM API in Server 1 for ModelA. Am I supposed to just duplicate models.py from Server 2 to Server 1? By just copying models.py over, I can use the ORM methods and trust the database routers that I set up to not do weird stuff when they syncdb.
This seems to be good enough right? I don't see any reason to use django-piston or those other restful API packages because in those cases, I have to still add all the extra code to recognize the model. Main reason I even dove into looking at the API packages is because I was wondering if there was a clean way of giving ORM access without duplicating the code.
Copying the code is pretty common. You can configure your settings to point to whatever database server you want.
As an app grows it is common to have to add webservers. One way this can be done is to copy your code base to another machine and run it behind a reverse proxy.
This means the exact same code is running on more than one machine, sharing a database backend.
Django provides an 'app' structure which you might want to look at. You can package an app and distribute it to another projecct.
I've been using django-auth-ldap for a while to auth against a single server (AUTH_LDAP_SERVER_URI in settings.py). There have been some changes in my organization recently, and I now need to be able to check against two different LDAP servers (actually: Active Directory, but I don't think that comes into play here). Unfortunately there is not a single location that has all of the user info I need.
Is there any way I can configure django-auth-ldap to check against more than 1 server? The documentation seems to assume a single server/URI. I'd also entertain ideas outside of django-auth-ldap, but I'd really like to stick with it if possible because it keeps things simple.
You would need to extend the custom auth handler to take an iterable for servers to check against and just step through them.
There is nothing stopping you from checking any number of directories for the information you need - there is no limitation in the underlying libraries.
django-auth-ldap 1.1 (just released) allows you to easily define multiple subclasses of the authentication backend that use different collections of settings. See http://packages.python.org/django-auth-ldap/#multiple-ldap-configs.
I created a database for a site i'm doing using Django as the admin backend. However because the server where the site is hosted on, won't be able to support Python, I find myself needing to do the front end in PHP and as such i've decided to use CodeIgniter along with Datamapper to map the models/relationship.
However DataMapper requires the tables to be in a specific format for it to work, and Django maps its tables differently, using the App name as the prefix in the table. I've tried using the prefix & join_prefix vars in datamapper but still doesn't map them correctly.
Has anyone used a combination of this? and if so how have the fixed the issue of db table names being inconsistent? Is there anything out there that i can use to make them work together?
----edit: clarification on backend---
Let me clarify: i'm going to be running the admin from a subdomain pointing to a python ready server. However i can't move the main domain name from the php only webserver because of certain constraints/binding contracts the company got itself in. and don't want to use cloaking/masking because of seo purposes.
i'm using the django admin because i'm using some packages to make a pretty/functional admin, such as grappelli for the admin template, along with its editor for editing news stories, etc. also using photologue to manage photos/galleries. etc.
If your problem is simply making Django use the same tables as your other software, use the db_column and db_table parameters in the models.
http://www.djangoproject.com/documentation/models/custom_columns/
Two apparent solutions:
Instead of hacking one or both to work well with each other, emulate the Django admin in PHP/CodeIgniter code. **
Get a server that supports Django. Make the frontend in Django.
Time-wise, either one of those solutions will be less involving than trying to make two different frameworks using different programming languages mesh well together. I can't imagine the future maintenance required to ensure everlasting compatibility and interoperability.
Also, I assume by saying:
I created a database for a site i'm doing using Django as the admin backend
You really mean that you modeled your apps using Django, and that you also intend on administrating the database that has resulted from this modeling in the Django admin. (In which case you already have your Models layer complete and should just try building the rest of the site in Django)
If that's the case then in your models you are going to need to define the exact column names (db_column) that DataMapper will expect, as well as manually define the table names (db_table), including M2M tables.
You may also have to define all of your primary keys manually, if DM expects something named differently.
Also:
If the server can't support Python, where are you going to be running your backend? Different server? Locally? This plan just isn't making a lot of sense.
** I would not suggest trying this. I had been attempting to make a CI backend that actually shared much of the same ideas as Django's admin, before I knew about Django's admin. And of course once discovering Django, I dropped the CI work immediately and continued on with what I have found to be a much more amazing framework that is much faster to develop on.
So as I understand you plan on using Django just because of django-admin, and you are trying to use CI for the actual site because the server runs PHP, right?
So why don't you use framework that generates something like Django's admin but that you can run on your server?
The Symfony Framework has a really nice admin generator, in the spirit of Django's and you might be able to run it on your server. This would save you from the maintainance nightmare that might come later as #jonwd7 answered
Need to integrate Django with an existing authentication system. That system has it's own database, API, login/logout,edit profile web pages and cookie.
(I may have to add a few additional profile fields stored/updated locally)
What's the proper approach to substitute the out-of-the-box authentication in Django?
The proper approach to substitute authentication from django's out-of-the-box to your own is to substitute your classes in the AUTHENTICATION_BACKENDS tuple in settings.py as described in http://docs.djangoproject.com/en/dev/topics/auth/#specifying-authentication-backends. This is incredibly useful for just the issue you're describing.
A good example of an authentication backend done this way is django-cas. This uses CAS to authenticate in a django application. You can use this as your template and just write hooks into your own authentication system identically.
HTH
I've created a custom authentication backend when I've had to do something similar to what you have to do. See: http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend
In the authenticate function you call your api to authenticate the user, and then map them to a django.contrib.auth.model.User object on some primary key, like username for example. If the primary key is something other than username I usually create a mapping object, or put it into the profile object for the project.
This depends on how you want to handle the problem. If you don't need to keep the existing system running, your best bet is to import their data into the django project.
If the authentication system must stay in tact, you might have to write a wrapper for django.auth. I've done this in the past using SQLAlchemy http://www.sqlalchemy.org to integrate to the external database.
It might be helpful to take a look at the Django 1.2 multi-db support http://djangoadvent.com/1.2/multiple-database-support
In either case I'd try to get the user information into django.auth rather than to write your own authentication system.