1.6.13 to 1.7.1 upgrade issues: ERROR (EXTERNAL IP): Internal Server Error: /r/213/
Since upgrading to 1.7.1 all new reviews have been running into this issue (backtrace below). I did some digging into the traceback that was generated and found the following: reviewboard/scmtools/hg.py line 215, the version variable being passed to parse_version is None. This is coming from line 213 from mercurial.__version__ import version When I run the line above from the command line I get back 1.9, but for some reason it is not working from the web server. I have not changed any set up with the web server since upgrading from 1.6.13 to 1.7.1, but this wasn't an issue before. I have verified the rb-site was properly upgraded. Is there something I missed somewhere? To get it to work in the mean time I hardcoded the version number for mercurial, which seems to have mitigated the issue (and made me feel really dirty), but I'm still not sure why it thinks it should break itself. Traceback (most recent call last): File /usr/lib/python2.6/site-packages/Django-1.4.3-py2.6.egg/django/core/handlers/base.py, line 111, in get_response response = callback(request, *callback_args, **callback_kwargs) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/accounts/decorators.py, line 20, in _check return login_required(view_func)(*args, **kwargs) File /usr/lib/python2.6/site-packages/Djblets-0.7.8-py2.6.egg/djblets/auth/util.py, line 47, in _checklogin return view_func(request, *args, **kwargs) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/reviews/views.py, line 728, in review_detail 'screenshots': screenshots, File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/reviews/views.py, line 124, in _make_review_request_context upload_diff_form = UploadDiffForm(review_request) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/reviews/forms.py, line 276, in __init__ data, *args, **kwargs) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/diffviewer/forms.py, line 51, in __init__ if self.repository.get_scmtool().get_diffs_use_absolute_paths(): File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/scmtools/models.py, line 134, in get_scmtool return cls(self) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/scmtools/hg.py, line 31, in __init__ self.client = HgClient(repository.path, repository.local_site) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/scmtools/hg.py, line 215, in __init__ if parse_version(version) = parse_version(1.2): File /usr/lib/python2.6/site-packages/distribute-0.6.30-py2.6.egg/pkg_resources.py, line 1984, in parse_version for part in _parse_version_parts(s.lower()): TypeError: 'NoneType' object is not callable -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Upgaded from 1.6.3 to 1.7.1 - Styles missing
I believe it is htdocs with an S on the end. Alias /static /var/www/reviewboard/htdocs/static I ran into the same problem. On Thursday, January 3, 2013 10:15:13 AM UTC-7, Brian wrote: Hello, I upgraded from v1.6.3 to v1.7.1 this morning using the following steps: easy_install -U ReviewBoard rb-site upgrade /var/www/reviewboard /etc/init.d/memcached restart service apache2 restart then found that I had to do: chown -R www-data /var/www/reviewboard/htdocs/media/ext service apache2 restart The upgrade seemed to go ok except the styles are missing when I look at our site, I just see text. I found here ( https://groups.google.com/forum/?fromgroups=#!topic/reviewboard/PRKV4CPZoZY) that I apparently missed something in the rb-site upgrade so I added Alias /static /var/www/reviewboard/htdoc/static to my Apache config and restarted Apache again. But I'm still not seeing the styles. Any ideas? Thanks, Brian -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: 1.6.13 to 1.7.1 upgrade issues: ERROR (EXTERNAL IP): Internal Server Error: /r/213/
Correct, Python 2.6.6. Everything else works, is also the weird thing. I hardcoded a version number if it came back as None (I guess I could add some logging to that if statement too) and it just keeps going. It generates the diffs fine, all the other integration options seem to work. So I have no idea what it could be. I'll add your logging and see if it comes back with anything interesting. On Thursday, January 3, 2013 2:40:03 PM UTC-7, Christian Hammond wrote: Hi Brian, Just to sanity check, when you run that manually, is it also using Python 2.6? It seems weird that we'd be able to import that file but not get the version. In my copy here, it's nothing but a straight-forward variable assignment in a file called __version__.py. It'd be interesting to add some logging there to print mercurial.__version__.__file__ and then look in there to see what it says. Christian -- Christian Hammond - chi...@chipx86.com javascript: Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Thu, Jan 3, 2013 at 7:55 AM, Brian Armstrong kf7...@gmail.comjavascript: wrote: Since upgrading to 1.7.1 all new reviews have been running into this issue (backtrace below). I did some digging into the traceback that was generated and found the following: reviewboard/scmtools/hg.py line 215, the version variable being passed to parse_version is None. This is coming from line 213 from mercurial.__version__ import version When I run the line above from the command line I get back 1.9, but for some reason it is not working from the web server. I have not changed any set up with the web server since upgrading from 1.6.13 to 1.7.1, but this wasn't an issue before. I have verified the rb-site was properly upgraded. Is there something I missed somewhere? To get it to work in the mean time I hardcoded the version number for mercurial, which seems to have mitigated the issue (and made me feel really dirty), but I'm still not sure why it thinks it should break itself. Traceback (most recent call last): File /usr/lib/python2.6/site-packages/Django-1.4.3-py2.6.egg/django/core/handlers/base.py, line 111, in get_response response = callback(request, *callback_args, **callback_kwargs) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/accounts/decorators.py, line 20, in _check return login_required(view_func)(*args, **kwargs) File /usr/lib/python2.6/site-packages/Djblets-0.7.8-py2.6.egg/djblets/auth/util.py, line 47, in _checklogin return view_func(request, *args, **kwargs) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/reviews/views.py, line 728, in review_detail 'screenshots': screenshots, File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/reviews/views.py, line 124, in _make_review_request_context upload_diff_form = UploadDiffForm(review_request) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/reviews/forms.py, line 276, in __init__ data, *args, **kwargs) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/diffviewer/forms.py, line 51, in __init__ if self.repository.get_scmtool().get_diffs_use_absolute_paths(): File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/scmtools/models.py, line 134, in get_scmtool return cls(self) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/scmtools/hg.py, line 31, in __init__ self.client = HgClient(repository.path, repository.local_site) File /usr/lib/python2.6/site-packages/ReviewBoard-1.7.1-py2.6.egg/reviewboard/scmtools/hg.py, line 215, in __init__ if parse_version(version) = parse_version(1.2): File /usr/lib/python2.6/site-packages/distribute-0.6.30-py2.6.egg/pkg_resources.py, line 1984, in parse_version for part in _parse_version_parts(s.lower()): TypeError: 'NoneType' object is not callable -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: It's too easy to upload diffs wrongly
I think the interface for uploading diffs is very minimalistic and vague about what to do. The first time, without fail, any of our developers have tried to use the upload diff interface it has failed to work properly and results in an error about not being able to apply the diff or being unable to find the parent revision. This has led to me spending time with each of these developers to train them how to properly upload diffs. I'd say something there is very broken if it doesn't work like people are expecting it to work and it doesn't have a clear explanation of what it is expecting. Also, if the diff can't be applied properly, it should show an error on the upload screen about it. They shouldn't have to click view diff every time to make sure it uploaded correctly. I think saying the fix for the confusing interface is to not use the interface and to use the command line tool instead is not actually a solution to the problem. It is also not an option for everyone (like our Skins team who just does CSS and Javascript and is scared of the command line). We have them using reviewboard, but they will only upload their diffs manually. They have run into this same kind of problem, and it just makes the tool overly complicated and not worth the time to learn. Giving this kind of solution to a problem is not only insufficient, but it also shows that the problem is real and the tool is lacking in functionality and clearness. If it's not understandable and usable, then it's broken. If it's broken, then it needs to be fixed. The correct fix should not be use something else. That being said, it is open source, so I'd love to see the diff of changes that Will made. They'd probably be helpful for our users too. On Friday, November 30, 2012 3:53:20 PM UTC-7, David Trowbridge wrote: It's correct to upload full diffs. The best way to do this is to use the post-review tool, which (with no arguments) will do the right thing. -David -David On Fri, Nov 30, 2012 at 2:49 PM, Will ultra...@gmail.com javascript:wrote: So... don't any users know how whether it's correct to upload full diffs or partial diffs? On Thursday, 22 November 2012 12:44:25 UTC, Will wrote: Where is it described in the documentation the correct way to make several diffs and upload them incrementally? We had a situation where one of our developers only uploaded partial diffs each time (just the changes since the last time he uploaded a diff), meaning there was no way to see his complete set of diffs together. I don't blame him because how was he supposed to know not to do that? We ended up hacking some extra instructions into the add review template and marking them bold red to try and prevent people doing this. ReviewBoard assumes all diffs are complete (from first commit to last), and it figures out the rest, allowing reviewers to easily drill down by revision if they want. If any of the uploaded diffs are not complete, then reviewers can completely miss changes that were made. a) where is the right way to add diffs documented? b) shouldn't reviewboard make it a lot more difficult to upload diffs wrongly -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Apache 403 with API PUT Requests
I switched it this morning to run as it's own VHost, but I also have it using lighttpd + fastcgi now. It worked without a hitch, so I think I'm just going to leave it this way and not bother with apache. A link I found listed a 503 as apache's default response to PUT requests, so I was probably running in to that. Thanks for your help! On Wednesday, September 12, 2012 4:11:14 PM UTC-6, Brian Armstrong wrote: Yes, it runs a couple things. I think, though, that I'm going to move it to a different machine where I can run it as it's own vhost, rather than as a path under the main vhost, and see if that fixes the issues. If not, it's probably an apache issue. I mostly just wanted to figure out if anyone had run into it before. I'll post an update if moving it to a dedicated vhost makes the difference. On Wednesday, September 12, 2012 3:31:35 PM UTC-6, Christian Hammond wrote: Is there anything else hosted on that Apache? It is indeed never getting to Review Board, and it sounds like something else is taking some ownership of that path. Christian On Sep 12, 2012, at 13:17, Brian Armstrong kf7...@gmail.com wrote: The Limit and Script directives are there from attempts to get it to work. As far as I can tell, they don't have any effect. I didn't have them when I first started getting the error, and - after removing - I still get it. I can get the error with or without cookies. When I use curl, I am sending along my auth information using '-u', which works just fine with POST. This seems like it is apache throwing the error, not django, but I'm just not sure what to do to fix it. I'm using: Firefox 15.0.1 ReviewBoard 1.6.11 Django 1.3.3 (final) Apache/2.2.3 Python 2.6.8 CentOS release 5.8 (Final) SELinux is disabled URL: PUT https://hostsite.com/reviews/api/review-requests/1/draft/ Request Data: api_format=jsondescription=Updating+description Request Headers Accept application/json, text/javascript, */* Accept-Encoding gzip, deflate Accept-Language en-us,en;q=0.5 Connection keep-alive Content-Length 48 Content-Type application/x-www-form-urlencoded; charset=UTF-8 Cookie rbsessionid=f9e5be5681ed545045d698d53ea4ff9f; (etc) DNT 1 Host hostsite.com Referer https://hostsite.com/reviews/r/1/ User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20100101 Firefox/15.0.1 X-Requested-With XMLHttpRequest Response: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title403 Forbidden/title /headbody h1Forbidden/h1 pYou don't have permission to access /reviews/api/review-requests/1/draft/ on this server./p /body/html Response Headers Connection close Content-Encoding gzip Content-Length 198 Content-Type text/html; charset=iso-8859-1 Date Wed, 12 Sep 2012 20:06:53 GMT Server Apache/2.2.3 (CentOS) Vary Accept-Encoding On Wednesday, September 12, 2012 1:22:31 PM UTC-6, Christian Hammond wrote: Hi Brian, Haven't seen that before. Well, first thing that stands out to me is that you shouldn't need the Limit/Script lines, do I'd get rid of them. You can get the 403 if you don't have cookies working right. Which version of Review Board are you using, and which browser? Most browsers have built-in development tools now, and you should be able to see the network activity. Can you find that, bring it up, and then reproduce it? You should be able to see the headers and the request/responses. If you can provide all these, it'd help me narrow it down. Christian On Sep 12, 2012, at 11:24, Brian Armstrong kf7...@gmail.com wrote: I am running reviewboard at the /reviews url of a server that handles many different things. Whenever I try to edit a review it makes an ajax PUT request to the API to update the item I changed. Here is what the Server Error Details shows me *Error Code:* 403 *Error Text:* Forbidden *Request URL:* /reviews/api/review-requests/1/draft/ *Request Data:* summary=Changing+the+summary This is being caused by apache2 (CentOS 5) with mod_wsgi. The only thing I get is an entry in the access log telling me the request was 403'd, nothing else. When using curl, I can get the requests to work every time by using POST instead of PUT. Here is the config section specific to reviewboard WSGIPassAuthorization On WSGIScriptAlias /reviews /var/reviewboard/ rb.dev.qualtrics.com/htdocs/reviewboard.wsgi/reviews Directory /var/reviewboard/rb.dev.qualtrics.com/htdocs AllowOverride All Options -Indexes FollowSymLinks +ExecCGI Order allow,deny Allow from all Limit PUT DELETE Allow from all /Limit Script PUT /reviews Script DELETE /reviews /Directory # Static media for reviewboard Alias /reviews/media /var/reviewboard/rb.dev.qualtrics.com/htdocs/media Alias /reviews/errordocs /var/reviewboard/ rb.dev.qualtrics.com/htdocs/errordocs Alias /reviews/favicon.ico /var/reviewboard
Apache 403 with API PUT Requests
I am running reviewboard at the /reviews url of a server that handles many different things. Whenever I try to edit a review it makes an ajax PUT request to the API to update the item I changed. Here is what the Server Error Details shows me *Error Code:* 403 *Error Text:* Forbidden *Request URL:* /reviews/api/review-requests/1/draft/ *Request Data:* summary=Changing+the+summary This is being caused by apache2 (CentOS 5) with mod_wsgi. The only thing I get is an entry in the access log telling me the request was 403'd, nothing else. When using curl, I can get the requests to work every time by using POST instead of PUT. Here is the config section specific to reviewboard WSGIPassAuthorization On WSGIScriptAlias /reviews /var/reviewboard/rb.dev.qualtrics.com/htdocs/reviewboard.wsgi/reviews Directory /var/reviewboard/rb.dev.qualtrics.com/htdocs AllowOverride All Options -Indexes FollowSymLinks +ExecCGI Order allow,deny Allow from all Limit PUT DELETE Allow from all /Limit Script PUT /reviews Script DELETE /reviews /Directory # Static media for reviewboard Alias /reviews/media /var/reviewboard/rb.dev.qualtrics.com/htdocs/media Alias /reviews/errordocs /var/reviewboard/rb.dev.qualtrics.com/htdocs/errordocs Alias /reviews/favicon.ico /var/reviewboard/rb.dev.qualtrics.com/htdocs/media/rbcommons/images/favicon.png I have searched the internet for hours trying to find a solution (since I know 403 is the default response to PUT requests with apache), but I haven't been able to find anything that works. I haven't been able to find anything relevant in this mailing list either. Wondering if anyone has any insight... -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Apache 403 with API PUT Requests
The Limit and Script directives are there from attempts to get it to work. As far as I can tell, they don't have any effect. I didn't have them when I first started getting the error, and - after removing - I still get it. I can get the error with or without cookies. When I use curl, I am sending along my auth information using '-u', which works just fine with POST. This seems like it is apache throwing the error, not django, but I'm just not sure what to do to fix it. I'm using: Firefox 15.0.1 ReviewBoard 1.6.11 Django 1.3.3 (final) Apache/2.2.3 Python 2.6.8 CentOS release 5.8 (Final) SELinux is disabled URL: PUT https://hostsite.com/reviews/api/review-requests/1/draft/ Request Data: api_format=jsondescription=Updating+description Request Headers Accept application/json, text/javascript, */* Accept-Encoding gzip, deflate Accept-Language en-us,en;q=0.5 Connection keep-alive Content-Length 48 Content-Type application/x-www-form-urlencoded; charset=UTF-8 Cookie rbsessionid=f9e5be5681ed545045d698d53ea4ff9f; (etc) DNT 1 Host hostsite.com Referer https://hostsite.com/reviews/r/1/ User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20100101 Firefox/15.0.1 X-Requested-With XMLHttpRequest Response: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title403 Forbidden/title /headbody h1Forbidden/h1 pYou don't have permission to access /reviews/api/review-requests/1/draft/ on this server./p /body/html Response Headers Connection close Content-Encoding gzip Content-Length 198 Content-Type text/html; charset=iso-8859-1 Date Wed, 12 Sep 2012 20:06:53 GMT Server Apache/2.2.3 (CentOS) Vary Accept-Encoding On Wednesday, September 12, 2012 1:22:31 PM UTC-6, Christian Hammond wrote: Hi Brian, Haven't seen that before. Well, first thing that stands out to me is that you shouldn't need the Limit/Script lines, do I'd get rid of them. You can get the 403 if you don't have cookies working right. Which version of Review Board are you using, and which browser? Most browsers have built-in development tools now, and you should be able to see the network activity. Can you find that, bring it up, and then reproduce it? You should be able to see the headers and the request/responses. If you can provide all these, it'd help me narrow it down. Christian On Sep 12, 2012, at 11:24, Brian Armstrong kf7...@gmail.com javascript: wrote: I am running reviewboard at the /reviews url of a server that handles many different things. Whenever I try to edit a review it makes an ajax PUT request to the API to update the item I changed. Here is what the Server Error Details shows me *Error Code:* 403 *Error Text:* Forbidden *Request URL:* /reviews/api/review-requests/1/draft/ *Request Data:* summary=Changing+the+summary This is being caused by apache2 (CentOS 5) with mod_wsgi. The only thing I get is an entry in the access log telling me the request was 403'd, nothing else. When using curl, I can get the requests to work every time by using POST instead of PUT. Here is the config section specific to reviewboard WSGIPassAuthorization On WSGIScriptAlias /reviews /var/reviewboard/ rb.dev.qualtrics.com/htdocs/reviewboard.wsgi/reviews Directory /var/reviewboard/rb.dev.qualtrics.com/htdocs AllowOverride All Options -Indexes FollowSymLinks +ExecCGI Order allow,deny Allow from all Limit PUT DELETE Allow from all /Limit Script PUT /reviews Script DELETE /reviews /Directory # Static media for reviewboard Alias /reviews/media /var/reviewboard/rb.dev.qualtrics.com/htdocs/media Alias /reviews/errordocs /var/reviewboard/ rb.dev.qualtrics.com/htdocs/errordocs Alias /reviews/favicon.ico /var/reviewboard/ rb.dev.qualtrics.com/htdocs/media/rbcommons/images/favicon.png I have searched the internet for hours trying to find a solution (since I know 403 is the default response to PUT requests with apache), but I haven't been able to find anything that works. I haven't been able to find anything relevant in this mailing list either. Wondering if anyone has any insight... -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Apache 403 with API PUT Requests
Yes, it runs a couple things. I think, though, that I'm going to move it to a different machine where I can run it as it's own vhost, rather than as a path under the main vhost, and see if that fixes the issues. If not, it's probably an apache issue. I mostly just wanted to figure out if anyone had run into it before. I'll post an update if moving it to a dedicated vhost makes the difference. On Wednesday, September 12, 2012 3:31:35 PM UTC-6, Christian Hammond wrote: Is there anything else hosted on that Apache? It is indeed never getting to Review Board, and it sounds like something else is taking some ownership of that path. Christian On Sep 12, 2012, at 13:17, Brian Armstrong kf7...@gmail.com javascript: wrote: The Limit and Script directives are there from attempts to get it to work. As far as I can tell, they don't have any effect. I didn't have them when I first started getting the error, and - after removing - I still get it. I can get the error with or without cookies. When I use curl, I am sending along my auth information using '-u', which works just fine with POST. This seems like it is apache throwing the error, not django, but I'm just not sure what to do to fix it. I'm using: Firefox 15.0.1 ReviewBoard 1.6.11 Django 1.3.3 (final) Apache/2.2.3 Python 2.6.8 CentOS release 5.8 (Final) SELinux is disabled URL: PUT https://hostsite.com/reviews/api/review-requests/1/draft/ Request Data: api_format=jsondescription=Updating+description Request Headers Accept application/json, text/javascript, */* Accept-Encoding gzip, deflate Accept-Language en-us,en;q=0.5 Connection keep-alive Content-Length 48 Content-Type application/x-www-form-urlencoded; charset=UTF-8 Cookie rbsessionid=f9e5be5681ed545045d698d53ea4ff9f; (etc) DNT 1 Host hostsite.com Referer https://hostsite.com/reviews/r/1/ User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20100101 Firefox/15.0.1 X-Requested-With XMLHttpRequest Response: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title403 Forbidden/title /headbody h1Forbidden/h1 pYou don't have permission to access /reviews/api/review-requests/1/draft/ on this server./p /body/html Response Headers Connection close Content-Encoding gzip Content-Length 198 Content-Type text/html; charset=iso-8859-1 Date Wed, 12 Sep 2012 20:06:53 GMT Server Apache/2.2.3 (CentOS) Vary Accept-Encoding On Wednesday, September 12, 2012 1:22:31 PM UTC-6, Christian Hammond wrote: Hi Brian, Haven't seen that before. Well, first thing that stands out to me is that you shouldn't need the Limit/Script lines, do I'd get rid of them. You can get the 403 if you don't have cookies working right. Which version of Review Board are you using, and which browser? Most browsers have built-in development tools now, and you should be able to see the network activity. Can you find that, bring it up, and then reproduce it? You should be able to see the headers and the request/responses. If you can provide all these, it'd help me narrow it down. Christian On Sep 12, 2012, at 11:24, Brian Armstrong kf7...@gmail.com wrote: I am running reviewboard at the /reviews url of a server that handles many different things. Whenever I try to edit a review it makes an ajax PUT request to the API to update the item I changed. Here is what the Server Error Details shows me *Error Code:* 403 *Error Text:* Forbidden *Request URL:* /reviews/api/review-requests/1/draft/ *Request Data:* summary=Changing+the+summary This is being caused by apache2 (CentOS 5) with mod_wsgi. The only thing I get is an entry in the access log telling me the request was 403'd, nothing else. When using curl, I can get the requests to work every time by using POST instead of PUT. Here is the config section specific to reviewboard WSGIPassAuthorization On WSGIScriptAlias /reviews /var/reviewboard/ rb.dev.qualtrics.com/htdocs/reviewboard.wsgi/reviews Directory /var/reviewboard/rb.dev.qualtrics.com/htdocs AllowOverride All Options -Indexes FollowSymLinks +ExecCGI Order allow,deny Allow from all Limit PUT DELETE Allow from all /Limit Script PUT /reviews Script DELETE /reviews /Directory # Static media for reviewboard Alias /reviews/media /var/reviewboard/rb.dev.qualtrics.com/htdocs/media Alias /reviews/errordocs /var/reviewboard/ rb.dev.qualtrics.com/htdocs/errordocs Alias /reviews/favicon.ico /var/reviewboard/ rb.dev.qualtrics.com/htdocs/media/rbcommons/images/favicon.png I have searched the internet for hours trying to find a solution (since I know 403 is the default response to PUT requests with apache), but I haven't been able to find anything that works. I haven't been able to find anything relevant in this mailing list either. Wondering if anyone has any insight... -- Want to help the Review Board project
