640: Admin->Settings->General->Site Settings->Server adds an extra slash to the end of the url.
- Fixed
- Review Board
| jeremy*******@gmai***** (Google Code) (Is this you? Claim this profile.) | |
 |
|
| Dec. 3, 2008 |
What's the URL of the page containing the problem? http://server:8000/admin/settings/general/ What steps will reproduce the problem? 1. Edit the server url on that page 2. After hitting save, there is a slash that I didn't type. 3. Edit a review, and look at the email. What is the expected output? What do you see instead? I expected valid urls in the emails. Instead I see urls like http://server:8000//r/20/ which break. What operating system are you using? What browser? client: windows/firefox server: linux Please provide any additional information below.
I encounter the same behavior. All generated URLs have an extra slash and are thus invalid.
I see this too. Apache loads the pages, but the session is broken so people keep complaining that they have to continuously re-login.
Fixed in r1531.
-
+ Fixed -
- Priority-Medium + Priority-Critical + Component-Settings + Milestone-Release1.0 -
+ chipx86
This is still occurring for us. Example follows (sanitized)...
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://<review.server>//reviewboard/r/63/
-----------------------------------------------------------
Review request for Rails and josh.
Summary
-------
blah. blah. blah.
This addresses bug --------.
http://our.bug.server/--------
Diffs
-----
Diff: http://<review.server>//reviewboard/r/63/diff
Testing
-------
Thanks,
Rusty
You may have to go into the admin UI and save again for this to be fixed.
I went into the Site Configuration and saved it again, and now the whole reviewboard is broken. Something broke! (Error 500) It appears something broke when you tried to go to here. This is either a bug in Review Board or a server configuration error. Please report this to your administrator. I can't seem to get any log details. Best I got with a test instance was: ./manage.py runserver --traceback 0.0.0.0:8000 Validating models... 0 errors found Django version 1.0-rc_1-SVN-unknown, using settings 'reviewboard.settings' Development server is running at http://0.0.0.0:8000/ Quit the server with CONTROL-C. [22/Oct/2008 12:40:07] "GET / HTTP/1.1" 500 526 Help? :(
OK. Not sure where the log files are supposed to be but I found the Debug setting
again. Here is the trace.
Traceback:
File "/var/lib/python-support/python2.5/django/core/handlers/base.py" in get_response
77. request.path_info)
File "/var/lib/python-support/python2.5/django/core/urlresolvers.py" in resolve
180. sub_match = pattern.resolve(new_path)
File "/var/lib/python-support/python2.5/django/core/urlresolvers.py" in resolve
178. for pattern in self.urlconf_module.urlpatterns:
File "/var/lib/python-support/python2.5/django/core/urlresolvers.py" in
_get_urlconf_module
197. self._urlconf_module = __import__(self.urlconf_name, {}, {}, [''])
File "/home/rusty/workspace/reviewboard/urls.py" in <module>
24. load_site_config()
File "/home/rusty/workspace/reviewboard/admin/siteconfig.py" in load_site_config
105. apply_django_settings(siteconfig, settings_map)
File "/home/rusty/workspace/reviewboard/djblets/siteconfig/django_settings.py" in
apply_django_settings
153. value = siteconfig.get(key)
File "/home/rusty/workspace/reviewboard/djblets/siteconfig/models.py" in get
59. return self.settings.get(key, default)
Exception Type: AttributeError at /reviewboard/
Exception Value: 'unicode' object has no attribute 'get'
Very strange, that certainly shouldn't be happening. What revision are you at? Does this still happen if you restart the server?
-
- Fixed + Confirmed
Restarted the apache, cleared memcache, tried the command line dev server. No luck. $ svn info Path: . URL: http://reviewboard.googlecode.com/svn/trunk/reviewboard Repository Root: http://reviewboard.googlecode.com/svn Repository UUID: 5efc13c4-1f27-0410-8691-ff2d1f55687e Revision: 1537 Node Kind: directory Schedule: normal Last Changed Author: chipx86 Last Changed Rev: 1537 Last Changed Date: 2008-10-14 23:48:25 -0700 (Tue, 14 Oct 2008) $ svn info Path: . URL: http://svn.navi.cx/misc/trunk/djblets/djblets Repository Root: http://svn.navi.cx/misc Repository UUID: 9a66fdd2-3ab9-0310-9df6-91dd0304fdbc Revision: 11900 Node Kind: directory Schedule: normal Last Changed Author: chipx86 Last Changed Rev: 11900 Last Changed Date: 2008-10-14 23:12:06 -0700 (Tue, 14 Oct 2008)
Two more things I recommend trying:
1) Go back to Django 1.0 and see if it fixes this problem at all.
2) Run ./manage.py shell and type the following:
>>> from djblets.siteconfig.models import SiteConfiguration
>>> siteconfig = SiteConfiguration.objects.get_current()
>>> print siteconfig.settings
Send that to me. There's probably nothing really in there aside from domain names
that are sensitive, but if you feel better, you can e-mail me directly with the
information.
We know there's a problem if it doesn't look like: {stuff here}
That is, if it's an empty string or begins/ends with quotes, something went really badly.
We were running r8914 of django (1.0 rc1). I have upgraded to a package from
debian(1.0 final), but the error has not changed.
Here is the output you requested. I also did a __class__ on it.
$ ./manage.py shell
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> from djblets.siteconfig.models import SiteConfiguration
>>> siteconfig = SiteConfiguration.objects.get_current()
>>> print siteconfig.settings
{u'mail_host_password': u'', u'cache_backend': u'locmem:///',
u'diffviewer_show_trailing_whitespace': True, u'site_upload_temp_dir': None,
u'locale_datetime_format': u'N j, Y, P', u'auth_ldap_tls': False, u'mail_host_user':
u'', u'locale_year_month_format': u'F Y', u'auth_ldap_uid_mask':
u'uid=%s,ou=users,dc=example,dc=com', u'mail_server_address': u'root@localhost',
u'auth_ldap_uri': u'', u'diffviewer_context_num_lines': 5,
u'diffviewer_paginate_orphans': 10, u'mail_send_review_mail': True,
u'site_media_root': u'/home/rusty/workspace/reviewboard/htdocs/media',
u'locale_language_code': u'en-us', u'auth_nis_email_domain': u'',
u'search_index_file': u'/home/rusty/workspace/reviewboard/searchindex',
u'auth_ldap_anon_bind_passwd': u'', u'site_prepend_www': False,
u'auth_ldap_anon_bind_uid': u'', u'mail_port': 25, u'locale_month_day_format': u'F
j', u'locale_time_format': u'P', u'locale_date_format': u'N j, Y',
u'auth_ldap_email_domain': u'', u'search_enable': True, u'mail_default_from':
u'webmaster@localhost', u'auth_custom_backends': [u''],
u'diffviewer_include_space_patterns': [u''], u'mail_use_tls': False,
u'site_admin_email': u'test@example.com', u'auth_backend': u'builtin',
u'locale_timezone': u'US/Pacific', u'site_domain_method': u'http',
u'cache_expiration_time': 2592000, u'diffviewer_paginate_by': 20,
u'locale_time_zone': u'US/Pacific', u'auth_require_sitewide_login': False,
u'site_upload_max_memory_size': 2621440, u'locale_default_charset': u'utf-8',
u'mail_host': u'localhost', u'diffviewer_syntax_highlighting': True,
u'site_media_url': u'/reviewboard/media/', u'site_admin_name': u'Test'}
>>> siteconfig.settings.__class__
<type 'unicode'>
Hmm.. It's __dict__ here. One of two things is happening. Either somehow the simplejson loading code isn't being executed and you're getting the raw data from the database, or somehow it's represented as a string in the database, causing simplejson to deserialize as a string. A couple more things to try. First, see what happens if, from that shell, you copy the output of that print command and then assign that directly to siteconfig.settings, so we're initializing it as a dict. Then call siteconfig.save(). If that fixes it, that's great. Maybe we'll have to add some protection to make sure it's always a dict in case it somehow gets messed up. If not, the next thing would be to modify JSONField in djblets/util/fields.py and add some debugging to the "loads" function to find out the raw data we're getting in and the raw data we're getting out, and then run the above command in comment 11 again.
ok, printing and resaving the data resolved the issue, but hitting save on the site configuration page causes it to happen again. If you think it might be at the database level, could it be a postgresql specific issue?
It's possible, though I'd hope not.
A workaround we can put in place is to check the resulting value from loads in
fields.py and, if it's a string, attempt to loads the result of that (catching any
errors and discarding that result). At that point we should have something that's valid.
Maybe you can try this.. Edit that fields.py file and, in loads, change:
return simplejson.loads(s, encoding=settings.DEFAULT_CHARSET)
to:
value = simplejson.loads(s, encoding=settings.DEFAULT_CHARSET)
if isinstance(value, basestring):
try:
value = simplejson.loads(value, encoding=settings.DEFAULT_CHARSET)
except:
pass
return value
See if that does anything useful.
I think this is all taken care of now. Please let me know if it's still happening to anyone.
-
- Confirmed + Fixed