I have installed the reviewboard in virtual environment and have created site reviewboard on ubuntu 13.10 using apache2 with mod_wsgi.
when i hit the
http://localhost
i was asked to upgarde the site
The version of Review Board running does not match the version the
site was last upgraded to. You are running 1.7.20 and the site was
last upgraded to 1.7.21.
Please upgrade your site to fix this by running:
and on upgraded
$ rb-site upgrade /home/naveen/venv-review/reviewboard
got
i got following message:
Updating database. This may take a while.
The log output below, including warnings and errors, can be ignored
unless upgrade fails.
------------------ ------------------ Creating tables ... Installing custom SQL ... Installing indexes ... Installed
0 object(s) from 0 fixture(s) No evolution required.
------------------- -------------------
Resetting in-database caches. Traceback (most recent call last):
File "/home/naveen/venv-review/bin/rb-site", line 9, in
load_entry_point('ReviewBoard==1.7.21', 'console_scripts', 'rb-site')() File
"/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/cmdline/rbsite.py", line 2027, in main
command.run() File "/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/cmdline/rbsite.py", line 1860, in run
site.run_manage_command("fixreviewcounts") File "/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/cmdline/rbsite.py", line 562, in run_manage_command
execute_manager(reviewboard.settings, [file, cmd] + params) File
"/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/init.py", line 459, in execute_manager
utility.execute() File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/init.py", line 382, in execute
self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/base.py",
line 196, in run_from_argv
self.execute(*args, **options.dict) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/base.py",
line 232, in execute
output = self.handle(*args, **options) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/core/management/base.py",
line 371, in handle
return self.handle_noargs(**options) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/ReviewBoard-1.7.21-py2.7.egg/reviewboard/reviews/management/commands/fixreviewcounts.py",
line 16, in handle_noargs
starred_public_request_count=None) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/manager.py",
line 185, in update
return self.get_query_set().update(*args, **kwargs) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/query.py",
line 536, in update
rows = query.get_compiler(self.db).execute_sql(None) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/sql/compiler.py",
line 988, in execute_sql
cursor = super(SQLUpdateCompiler, self).execute_sql(result_type) File
"/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/models/sql/compiler.py",
line 818, in execute_sql
cursor.execute(sql, params) File "/home/naveen/venv-review/local/lib/python2.7/site-packages/Django-1.4.10-py2.7.egg/django/db/backends/sqlite3/base.py", line 344, in execute
return Database.Cursor.execute(self, query, params) django.db.utils.DatabaseError: attempt to write a readonly database
the sqlite database directory has been given access to server (www-data) like :
sudo chown www-data /home/naveen/venv-review/reviewboard/data
Does www-data should have read/write access of site , reviewboard, if it is the case ?
Update *
checking apache2 user
ps aux | grep apache2
root 1146 0.0 0.0 84208 3928 ? Ss 11:19 0:00 /usr/sbin/apache2 -k start
www-data 3632 0.1 0.6 698464 51056 ? Sl 11:34 0:01 /usr/sbin/apache2 -k start
www-data 3742 0.1 0.6 698480 51032 ? Sl 11:34 0:01 /usr/sbin/apache2 -k start
naveen 7162 0.0 0.0 13652 940 pts/1 S+ 11:53 0:00 grep apache2
The sqlite3 file, not only the directory, have to be owned and have to be writeable by the user running the web server.
so you may try running, from a terminal shell:
sudo chown -R www-data /home/naveen/venv-review/reviewboard/data
sudo chmod -R u+w /home/naveen/venv-review/reviewboard/data/*
the first command recursively change the owner of the files inside the folder, the second one ensures the users have writing permissions on these files.
Related
There are similar questions but my set of configuration is not the
same.I downloaded the wkhtmltopdf from wkhtmltopdf.org, placed on the
project folder, i cant figure out why im still getting access denied.
Trying to point django to run the wkhtmltopdf in order to generate a pdf file.
Running NGINX with UNICORN
Using SUPERVISOR
Ubuntu 16
in my unicorn_supervisor log i got:
Internal Server Error: /invoice/1/pdf
Traceback (most recent call last):emphasized text
File "/home/instantuser/app/lib/python3.5/site-packages/django/core/handlers/exception.py", line 39, in inner
response = get_response(request)
File "/home/instantuser/app/lib/python3.5/site-packages/django/core/handlers/base.py", line 217, in _get_respons e
response = self.process_exception_by_middleware(e, request)
File "/home/instantuser/app/lib/python3.5/site-packages/django/core/handlers/base.py", line 215, in _get_respons e
response = response.render()
File "/home/instantuser/app/lib/python3.5/site-packages/django/template/response.py", line 109, in render
self.content = self.rendered_content
File "/home/instantuser/app/lib/python3.5/site-packages/wkhtmltopdf/views.py", line 78, in rendered_content
cmd_options=cmd_options
File "/home/instantuser/app/lib/python3.5/site-packages/wkhtmltopdf/utils.py", line 186, in render_pdf_from_temp late
cmd_options=cmd_options)
File "/home/instantuser/app/lib/python3.5/site-packages/wkhtmltopdf/utils.py", line 124, in convert_to_pdf
return wkhtmltopdf(pages=filename, **cmd_options)
File "/home/instantuser/app/lib/python3.5/site-packages/wkhtmltopdf/utils.py", line 110, in wkhtmltopdf
return check_output(ck_args, **ck_kwargs)
File "/usr/lib/python3.5/subprocess.py", line 626, in check_output
**kwargs).stdout
File "/usr/lib/python3.5/subprocess.py", line 693, in run
with Popen(*popenargs, **kwargs) as process:
File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
restore_signals, start_new_session)
File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
raise child_exception_type(errno_num, err_msg)
PermissionError: [Errno 13] Permission denied
The wkhtmltopdf file:
-rwxr-xr-x 1 instantuser instantuser 39804584 Nov 22 10:11 wkhtmltopdf
Unicorn process:
instant+ 2949 0.1 0.5 70344 23216 ? S 18:51 0:00 /home/instantuser/app/bin/python3 ../bin/gunicorn instanthst.wsgi:application --name instanthst --workers 3 --user=instantuser --group=instantuser --bind=unix:/home/instantuser/app/instanthst/run/gunicorn.sock --log-level=debug --log-file=-
instant+ 2954 0.3 1.2 171712 51992 ? S 18:51 0:00 /home/instantuser/app/bin/python3 ../bin/gunicorn instanthst.wsgi:application --name instanthst --workers 3 --user=instantuser --group=instantuser --bind=unix:/home/instantuser/app/instanthst/run/gunicorn.sock --log-level=debug --log-file=-
instant+ 2955 0.3 1.2 171704 51936 ? S 18:51 0:00 /home/instantuser/app/bin/python3 ../bin/gunicorn instanthst.wsgi:application --name instanthst --workers 3 --user=instantuser --group=instantuser --bind=unix:/home/instantuser/app/instanthst/run/gunicorn.sock --log-level=debug --log-file=-
instant+ 2957 0.3 1.2 171568 51960 ? S 18:51 0:00 /home/instantuser/app/bin/python3 ../bin/gunicorn instanthst.wsgi:application --name instanthst --workers 3 --user=instantuser --group=instantuser --bind=unix:/home/instantuser/app/instanthst/run/gunicorn.sock --log-level=debug --log-file=-
ubuntu 2970 0.0 0.0 12944 964 pts/0 S+ 18:53 0:00 grep --color=auto unicorn
NGINX Process
root 3006 0.0 0.0 125112 1460 ? Ss 18:55 0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 3007 0.0 0.0 125436 3108 ? S 18:55 0:00 nginx: worker process
www-data 3008 0.0 0.1 125712 5060 ? S 18:55 0:00 nginx: worker process
ubuntu 3104 0.0 0.0 12944 940 pts/0 S+ 19:09 0:00 grep --color=auto nginx
Why am I getting access denied since the wkhtmltopdf file owner is the same running unicorn?
I'm able to run the command in the terminal but python cant run it. why?
I solve this problem by creating an shell script file to call the wkhtmltopdf.
wkhtmltopdf.sh
#!/bin/sh
xvfb-run -a -s "-screen 0 1024x768x16" wkhtmltopdf $*
Thank you all for the help.
Just use
sudo su
or
sudo command
That will run it as superuser and bypass all permissions. I the case that you Don't have access to superuser, I am not sure. This sometimes happens to me when I am trying to run something that is not supposed to be ran. Though I use ubuntu 14.04, so I don't understand this as well as others might.
I am using python 3.5 and windows 10, but had the same issue using windows 8, and that is the traceback i get while trying to runserver:
Traceback (most recent call last):
File "C:\Users\noabendor87\documents\otree\manage.py", line 10, in
execute_from_command_line(sys.argv, script_file=file)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\otree\management\cli.py", line
177, in execute_from_command_line
utility.execute()
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\core\management__init__
.py", line 346, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\core\management\base.py"
, line 394, in run_from_argv
self.execute(*args, **cmd_options)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\core\management\commands
\runserver.py", line 49, in execute
super(Command, self).execute(*args, **options)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\core\management\base.py"
, line 445, in execute
output = self.handle(*args, **options)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\core\management\commands
\runserver.py", line 88, in handle
self.run(**options)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\core\management\commands
\runserver.py", line 97, in run
autoreload.main(self.inner_run, None, options)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\utils\autoreload.py", li
ne 336, in main
reloader(wrapped_main_func, args, kwargs)
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\utils\autoreload.py", li
ne 307, in python_reloader
exit_code = restart_with_reloader()
File "c:\users\noabendor87\appdata\local\programs\python\python35-32\lib\site-packages\django\utils\autoreload.py", li
ne 293, in restart_with_reloader
exit_code = os.spawnve(os.P_WAIT, sys.executable, args, new_environ)
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character
I have already tried following the instructions in the following link:
http://stackoverflow.com/questions/25714826/error-in-manage-py-runserver-with-django-on-windows-8-1
but it did not help.
This is how the lines of code look like:
enter image description here
(Since Im a new user I cannot paste the image to the original post)
Anyone have encountered something similar and have a solution?
I used to have similar problems because of the difficulties with the virtual environment in windows 10. Try running the powershell as an administrator and do "Set-ExecutionPolicy RemoteSigned" or "Set-ExecutionPolicy Unrestricted" if remotesigned does not work. Do this before activating the virtualenv.
first I will like you check the django version you are working with my "type python -m django --version" or "pip freeze". check weather its compatible with the python version on your pc. if it's not install compatible python version. then check weather "init.py" is within your project directory, if not add it to your project directory. then run "Set-ExecutionPolicy -Scope CurrentUser Unrestricted" on your terminal. then run activate your virtualenv, then run "python manage.py runserver"
[EDIT]: I'm able to reproduce this without any of my own custom code. I just created a fresh Linode image running Ubuntu 14.04 and installed Docker according to the steps on Docker's website.
I then ran:
docker run -d --name db postgres
and can see it running:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
9d335e8fc70b postgres "/docker-entrypoint. 7 minutes ago Up 7 minutes 5432/tcp db
Then I start an interactive Ubuntu container, linked to db, and try to test the link via nc and curl:
$docker run -it --link db ubuntu /bin/bash
root#eb02f4e7b89e:/# apt-get install curl
...
root#eb02f4e7b89e:/# curl http://$DB_PORT_5432_TCP_ADDR:$DB_PORT_5432_TCP_PORT/
curl: (7) Failed to connect to 172.17.0.2 port 5432: Connection timed out
What am I missing?
I'm trying to link a postgres container with an app container running Django but it doesn't seem to be linking properly.
The commands to start the containers were:
$ docker run -d --name db postgres
$ docker run -d --name web --link db -p 8000:80 test_image
Both containers appear to be running fine:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5838047eb14c test_image "/test/.docker/st 40 minutes ago Up 40 minutes 0.0.0.0:8000->80/tcp web
d2d6754430a2 postgres "/docker-entrypoint. 44 minutes ago Up 44 minutes 5432/tcp db
And seem to be correctly linked:
$ docker inspect -f "{{ .HostConfig.Links }}" web
[/db:/web/db]
However, when I try to run "python manage.py migrate" in the web container it doesn't seem to be able to connect to the postgres container:
# python manage.py migrate
Traceback (most recent call last):
File "manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 338, in execute_from_command_line
utility.execute()
File "/usr/local/lib/python2.7/dist-packages/django/core/management/__init__.py", line 330, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 390, in run_from_argv
self.execute(*args, **cmd_options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/base.py", line 441, in execute
output = self.handle(*args, **options)
File "/usr/local/lib/python2.7/dist-packages/django/core/management/commands/migrate.py", line 93, in handle
executor = MigrationExecutor(connection, self.migration_progress_callback)
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/executor.py", line 19, in __init__
self.loader = MigrationLoader(self.connection)
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 47, in __init__
self.build_graph()
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/loader.py", line 180, in build_graph
self.applied_migrations = recorder.applied_migrations()
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/recorder.py", line 59, in applied_migrations
self.ensure_schema()
File "/usr/local/lib/python2.7/dist-packages/django/db/migrations/recorder.py", line 49, in ensure_schema
if self.Migration._meta.db_table in self.connection.introspection.table_names(self.connection.cursor()):
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 164, in cursor
cursor = self.make_cursor(self._cursor())
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 135, in _cursor
self.ensure_connection()
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 130, in ensure_connection
self.connect()
File "/usr/local/lib/python2.7/dist-packages/django/db/utils.py", line 97, in __exit__
six.reraise(dj_exc_type, dj_exc_value, traceback)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 130, in ensure_connection
self.connect()
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/base/base.py", line 119, in connect
self.connection = self.get_new_connection(conn_params)
File "/usr/local/lib/python2.7/dist-packages/django/db/backends/postgresql_psycopg2/base.py", line 172, in get_new_connection
connection = Database.connect(**conn_params)
File "/usr/lib/python2.7/dist-packages/psycopg2/__init__.py", line 179, in connect
connection_factory=connection_factory, async=async)
django.db.utils.OperationalError: could not connect to server: Connection timed out
Is the server running on host "db" (172.17.0.42) and accepting
TCP/IP connections on port 5432?
I'm able to connect to the postgres container directly:
$ docker exec -it db bash
root#d2d6754430a2:/# cat /etc/hosts
172.17.0.42 d2d6754430a2
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
root#d2d6754430a2:/# su postgres
$ psql
psql (9.4.4)
Type "help" for help.
postgres=#
But not from inside the web container:
# curl http://$DB_PORT_5432_TCP_ADDR:$DB_PORT_5432_TCP_PORT/
curl: (7) Failed to connect to 172.17.0.42 port 5432: Connection timed out
My host machine is running Ubuntu 14.04.
Any ideas what I'm missing?
Check that your postgresql.conf has listen_addresses = '*'
The default is listen_addresses = 'localhost', which would behave in the manner you describe.
Edit:
This works for me, does it work for you?
$ docker pull postgres
$ docker pull django
$ docker run -d --name db -d postgres
$ docker run -it --link db:db django bash
root#11c767bd3d09:/# psql -h db -U postgres
psql (9.4.3, server 9.4.4)
Type "help" for help.
postgres=#
Edit (Docker 1.7.1 output)
$ docker rm $(docker ps -a -q)
$ docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
django latest 29755dd6751b 3 days ago 434.5 MB
postgres latest f33438ff9aef 3 days ago 265.5 MB
$ docker -v
Docker version 1.7.1, build 786b29d
$ docker run -d --name db -d postgres
$ docker run -it --link db:db django bash
root#11c767bd3d09:/# psql -h db -U postgres
psql (9.4.3, server 9.4.4)
Type "help" for help.
postgres=#
I'm using django v1.7.0b4 and celery v3.1.1. Followed steps according to the django installation guide. But I'm stuck with the below error.
$ ./manage.py celeryd --help
Starting server in DEVELOPMENT Mode
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/Library/Python/2.7/site-packages/django/core/management/__init__.py", line 427, in execute_from_command_line
utility.execute()
File "/Library/Python/2.7/site-packages/django/core/management/__init__.py", line 419, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/Library/Python/2.7/site-packages/django_celery-3.1.10-py2.7.egg/djcelery/management/base.py", line 77, in run_from_argv
return super(CeleryCommand, self).run_from_argv(argv)
File "/Library/Python/2.7/site-packages/django/core/management/base.py", line 284, in run_from_argv
parser = self.create_parser(argv[0], argv[1])
File "/Library/Python/2.7/site-packages/django/core/management/base.py", line 265, in create_parser
option_list=self.option_list)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1214, in __init__
add_help=add_help_option)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1256, in _populate_option_list
self.add_options(option_list)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1039, in add_options
self.add_option(option)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 1020, in add_option
self._check_conflict(option)
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/optparse.py", line 995, in _check_conflict
option)
optparse.OptionConflictError: option -C/--no-color: conflicting option string(s): --no-color
Is any one else facing the same issue ?
Edited :
Working good in django v1.6.5.
You should use ./manage.py celery worker instead of ./manage.py celeryd
Looks like there is an bug when you use:
django==1.7b4
celery==3.1.11
django-celery==3.1.10
Few tips which will help you avoid this issues:
When you are starting playing with a project stay away from beta releases, use stable release.
Don't use deprecated methods: ./manage.py celeryd is old deprecated alias for ./manage celery worker
The incompatibility in django-celery was fixed two months ago: https://github.com/celery/django-celery/pull/320. If you are using virtualenv, then you could monkey-patch like this:
sed "s/\(= \['--app', '--loader', '--config'\)\]/\1, '--no-color']/" -i \
"$VIRTUAL_ENV/lib/python3.4/site-packages/djcelery/management/base.py"
Tested with Celery 3.1.13 and django-celery 3.1.10.
I am running flask, pymongo and flask-login as a stack.
My flask app is running fine locally, but once I deploy it with uwsgi on nginx, I get a strange unicode error from flask_login extension.
In short:
TypeError: decoding Unicode is not supported
Traceback:
[pid: 21753|app: 0|req: 5/5] 84.207.253.34 () {38 vars in 600 bytes} [Thu Jun 13 16:51:08 2013] GET / => generated 0 bytes in 4 msecs (HTTP/1.1 500) 0 headers in 0 bytes (0 switches on core 0)
Traceback (most recent call last):
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1836, in __call__
return self.wsgi_app(environ, start_response)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1820, in wsgi_app
response = self.make_response(self.handle_exception(e))
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1403, in handle_exception
reraise(exc_type, exc_value, tb)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app
response = self.full_dispatch_request()
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1477, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1381, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1473, in full_dispatch_request
rv = self.preprocess_request()
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask/app.py", line 1666, in preprocess_request
rv = func()
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask_login.py", line 311, in _load_user
deleted = self._session_protection()
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask_login.py", line 325, in _session_protection
ident = _create_identifier()
File "/myproject/myproject-env/local/lib/python2.7/site-packages/flask_login.py", line 133, in _create_identifier
request.headers.get("User-Agent")), 'utf8', errors='replace')
TypeError: decoding Unicode is not supported
Why is this not happening in dev environment? Hence it must be somehow related to uwsgi on nginx. Any suggestions? Many Thanks
The problem won't be solved by downgrading flask alone, because even installing flask==0.9 would install the latest dependencies, which is the bad werkzeug==0.9
Hence you better install the following in this order:
pip install werkzeug==0.8.3
pip install flask==0.9
pip install Flask-Login==0.1.3
flask login, can then be the latest version 0.1.3. No harm done there.
This stack works for me.
Hope this helps, until the emergency patch is out.
I am having the very same problem on my dev environment, with Flask 0.10 and Flask-Login 0.1.3
looks like flask 0.10 now has unicode request headers so flask-login explodes when trying to encode an already encoded string...
Flask_login people are already working on it:
https://github.com/maxcountryman/flask-login/issues/78
(EDIT) instant road to temporary happiness (as seen in github twin thread, thx Kofalt & Kave!)
pip uninstall flask ; pip uninstall werkzeug ; pip uninstall Flask-Login ; pip install werkzeug==0.8.3 ; pip install flask==0.9 ; pip install Flask-Login==0.1.3
My fork which fixes this issue:
https://github.com/jgelens/flask-login/tree/0.1.4
Install using:
pip install https://github.com/jgelens/flask-login/archive/0f07b8fa783c40d09cb284d442a526f067bab28b.zip#egg=flask-login
As per losu S., this looks to be a Flask 0.10 problem. Try to install previous version of Flask in your virtual environment using:
pip install Flask==0.9