LDAP: providers dict does not have 'ldap'
I have a working AskBot system on CentOS 6.x, askbot version 0.7.53, so I have successfully used LDAP before. However, I am trying to install a completely new AskBot (not upgrade) on a different server, Ubuntu 16.04, askbot version 0.10.0, and I cannot get LDAP working on the new system.
I only want LDAP login and local login. I have turned off all others. I have the following settings:
- Login provider settings: "Activate local password login" is checked
- Login provider settings: "Activate ??? login" for AOL,Blogger,ClaimID,Facebook,etc. are all unchecked
- LDAP login configuration: "Use LDAP authentication for the password login" is checked
I'm using runserver to debug. I can use pdb.set_trace() to gather more information, if that would help. When I try to login using my admin user (local login), it works fine. When I try to login using LDAP, I get a KeyError (see below). Note that if I hack the code to get past this error, thus allowing AskBot to create the new user in its tables, I do not hit the error again. It apparently only happens during the initial login via LDAP. But my hack is not usable; I just did it to see if the login would work.
Environment:
Request Method: POST
Request URL: .../account/signin/
Django Version: 1.8.13
Python Version: 2.7.11
Installed Applications:
('longerusername',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.contrib.staticfiles',
'django.contrib.admin',
'django.contrib.humanize',
'django.contrib.sitemaps',
'django.contrib.messages',
'compressor',
'askbot',
'askbot.deps.django_authopenid',
'askbot.deps.livesettings',
'keyedcache',
'robots',
'django_countries',
'djcelery',
'djkombu',
'followit',
'tinymce',
'askbot.deps.group_messaging',
'captcha',
'avatar')
Installed Middleware:
('django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'askbot.middleware.anon_user.ConnectToSessionMessagesMiddleware',
'askbot.middleware.forum_mode.ForumModeMiddleware',
'askbot.middleware.cancel.CancelActionMiddleware',
'askbot.middleware.view_log.ViewLogMiddleware',
'askbot.middleware.spaceless.SpacelessMiddleware',
'askbot.middleware.csrf.CsrfViewMiddleware')
Traceback:
File "/opt/virtenvs/askbot/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
132. response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/opt/virtenvs/askbot/local/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapped_view
110. response = view_func(request, *args, **kwargs)
File "/opt/virtenvs/askbot/local/lib/python2.7/site-packages/askbot/deps/django_authopenid/views.py" in signin
484. redirect_url = next_url
File "/opt/virtenvs/askbot/local/lib/python2.7/site-packages/askbot/deps/django_authopenid/views.py" in finalize_generic_signin
1012. redirect_url=redirect_url
File "/opt/virtenvs/askbot/local/lib/python2.7/site-packages/askbot/deps/django_authopenid/views.py" in decorated
234. return func(request, *args, **kwargs)
File "/opt/virtenvs/askbot/local/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapped_view
110. response = view_func(request, *args, **kwargs)
File "/opt/virtenvs/askbot/local/lib/python2.7/site-packages/askbot/deps/django_authopenid/views.py" in register
1045. provider_data = providers[login_provider_name]
Exception Type: KeyError at /account/signin/
Exception Value: 'ldap'
The 'providers' dictionary only has one key in it at the time of this attempted dictionary access: local. The code ...
Comments
@dccarson, could you try checking out the latest code from the Askbot master branch at github? https://github.com/ASKBOT/askbot-devel. I remember fixing some issues related to LDAP, but it might not have made it to the 0.10.0
@Evgeny : I have reconsidered my method and have decided to continue on the 0.7.x stream for now. I need to very quickly bring an askbot server back online. So, why, when I start out with a fresh virtualenv, do I get import errors? Shouldn't `pip install "askbot<0.8"` give me the **correct** versions of everything needed? First, I get an error importing `import_string` during the syncdb step. This is easy to hack, which is what I did because I need to get this working quickly. Now, when I try to run `python manage.py migrate askbot` I get an error importing `migrations`. According to answers I have read elsewhere, `migrations` is not in Django until 1.7. But why is `migrations` being used when pip should have installed the correct version of everything? I have tried many different approaches and every time, I hit errors. At ... (more)
@dccarson - it could be that errors occur because askbot did not fix upper version of dependency libraries - this can lead to the package breaking in the future. In the upcoming releases this will be fixed. Testing currently the 0.7.x branch for a fresh deployment, will post an update shortly.
I've test-deployed the latest commit from the 0.7.x branch of the github repository into an empty virtualenv, worked for me. I will pin the latest acceptable dependency versions to avoid the potential dependency incompatibility issue. @dccarson, lease let me know how ldap works with this version.
OK. Should I be waiting for an 0.7.56 version before I try again? If not, then can you give me the exact git command to use to get the version where you are pinning dependencies. I am not a git user.
I did the following -- results in an "invalid JSON" error: """ virtualenv /opt/askbot source /opt/askbot/bin/activate git clone https://github.com/ASKBOT/askbot-devel.git myaskbotgit cd myaskbotgit git checkout 0.7.x python setup.py install askbot-setup pip install mysql-python cd /top/of/my/askbot/home python manage.py collectstatic python manage.py syncdb (note: existing db) python manage.py migrate askbot python manage.py migrate django_authopenid python manage.py runserver 1.2.3.4:8090 """ All of this worked without error, which indicates a change from my previous attempts. I always got at least one error with dependency issues before. However, when I try to open the front page, I get a ValidationError. Note that I have not tried to login yet. @Evgeny, should we take this offline?
Is "markdown" allowed in comments? My previous comment is not being formatted and is therefore very difficult to read. I am now trying to put the same information in an answer, but every time I submit the answer, it does not go through. Update: I cannot submit my answer version of the comment above, no matter how many times I try. I'm not getting any error--it just does not get submitted. If you can manage to read the steps I took in the comment above, then go to the following to see the stack trace: http <colon-slash-slash> dpaste.com/0EE2GJJ (Note: I do not have enough karma to use the actual link.)
@dccarson 0.7.56 will be ready tomorrow, almost done. markdown is allowed in the comments if you configure the comments editor to be the same as for the Q&A.
@dccarson, please try the 0.7.56 now and let me know how ldap setup works for you.
@Evgeny, I installed 0.7.56 and the installation itself was clean. This is a nice improvement--thank you. However, when I run runserver to debug and then attempt to open my browser, I get a JSON validation error. Note that I have NOT attemped to login, using LDAP or any other method. I am just trying to open the front page. Do you think we could take this offline? You should be able to see my e-mail address in your database. Send me an e-mail and then we can discuss off of this thread.
The traceback can be seen here: http <colon-slash-slash> dpaste.com/09N669T
I am at an impasse unless I can get some help debugging this issue. We cannot abandon the database of questions we already have, but I need to update my code base. The current deployment is somehow corrupted and does not allow certain operations (altering a profile, for example). I think if I can get the new, fresh installation using 0.7.56 to get past this JSON error, then the deployment will be fully functional again. I am happy to help in debugging by gathering information. I would need instructions on what to gather. As I said before, this may be more productive taken offline, but I am also happy to post my debug info here, if that is more useful. Thanks.
Any chance of help?
Is there some method of scrubbing a database that might eliminate what is possibly a database corruption issue? Any other hope of getting any help on this issue?
Probably trying to dump/restore the database? Also if you locate the corrupted records, you might try to delete them and then dump/restore into a blank database. Have you resolved the JSON issue? Sounds like it might be due to some version incompatibility (the latest versions of askbot are more stringent on checking the dependency versions, but it might happen that the dependency of dependency and so forth does not run such validation).
No, I have not resolved the JSON issue. I have no idea what it is, how to resolve it. I don't even know, for sure, if the database is corrupted. But, that is my best logical guess as to why we would get a JSON error. I will try dumping/restoring the database and see what that shows. Thanks.
We have an old server running 0.7.53. It only partially works, but the data cannot be lost. I am trying to install a fresh installation on a new server, using 0.7.56, so I can migrate the data from the old to the new server. To do so, I used the mysqldump file from the 0.7.53 server and populated the database on the 0.7.56 server. But the new installation is unusable because it hits the JSON error immediately. I also tried an experiment with my new installation, where I do NOT transfer any data to the new database, to test the installation itself. This works. I can open the home page, but without any data. One thing I noticed about the empty db experiment might be important: When I ran 'manage.py migrate askbot' on the empty db, a lot of stuff happened ... (more)