GNOME Bugzilla – Bug 629715
Tomboy fails to authenticate on Django 1.2
Last modified: 2010-09-16 13:48:41 UTC
When using snowy with Django 1.2 it appears that tomboy fails to authenticate. Log from tomboy: 9/14/2010 6:06:30 PM [ERROR]: Caught exception. Message: The remote server returned an error: (403) Forbidden. 9/14/2010 6:06:30 PM [ERROR]: Stack trace for previous exception: at System.Net.HttpWebRequest.CheckFinalStatus (System.Net.WebAsyncResult result) [0x00000] in <filename unknown>:0 at System.Net.HttpWebRequest.SetResponseData (System.Net.WebConnectionData data) [0x00000] in <filename unknown>:0 9/14/2010 6:06:30 PM [ERROR]: Rest of stack trace for above exception: at System.Environment.get_StackTrace() at Tomboy.WebSync.Api.OAuth.MakeWebRequest(RequestMethod method, System.String url, System.Collections.Generic.List`1 parameters, System.String postData) at Tomboy.WebSync.Api.OAuth.WebRequest(RequestMethod method, System.String url, System.String postData) at Tomboy.WebSync.Api.OAuth.Post(System.String uri, IDictionary`2 queryParameters, System.String postValue) at Tomboy.WebSync.Api.OAuth.GetAuthorizationUrl() at Tomboy.WebSync.WebSyncPreferencesWidget.OnAuthButtonClicked(System.Object sender, System.EventArgs args) at System.Reflection.MonoMethod.InternalInvoke(System.Object , System.Object[] , System.Exception ByRef ) at System.Reflection.MonoMethod.Invoke(System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) at System.Reflection.MethodBase.Invoke(System.Object obj, System.Object[] parameters) at System.Delegate.DynamicInvokeImpl(System.Object[] args) at System.MulticastDelegate.DynamicInvokeImpl(System.Object[] args) at System.Delegate.DynamicInvoke(System.Object[] args) at GLib.Signal.ClosureInvokedCB(System.Object o, GLib.ClosureInvokedArgs args) at GLib.SignalClosure.Invoke(GLib.ClosureInvokedArgs args) at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data) at Gtk.Application.gtk_main() at Gtk.Application.Run() at Gnome.Program.Run() at Tomboy.GnomeApplication.StartMainLoop() at Tomboy.Application.StartMainLoop() at Tomboy.Tomboy.StartTrayIcon() at Tomboy.Tomboy.Main(System.String[] args) 9/14/2010 6:06:30 PM [ERROR]: Failed to get auth URL from https://snowy.pyther.net. Exception was: System.Net.WebException: The remote server returned an error: (403) Forbidden. at System.Net.HttpWebRequest.CheckFinalStatus (System.Net.WebAsyncResult result) [0x00000] in <filename unknown>:0 at System.Net.HttpWebRequest.SetResponseData (System.Net.WebConnectionData data) [0x00000] in <filename unknown>:0 Log from http server: 10.20.1.208 snowy.pyther.net - [14/Sep/2010:18:06:29 -0400] "GET /api/1.0 HTTP/1.1" 301 0 "-" "-" 10.20.1.208 snowy.pyther.net - [14/Sep/2010:18:06:29 -0400] "GET /api/1.0/ HTTP/1.1" 200 276 "-" "-" 10.20.1.208 snowy.pyther.net - [14/Sep/2010:18:06:29 -0400] "POST /oauth/request_token/ HTTP/1.1" 403 2799 "-" "-" 10.20.1.208 snowy.pyther.net - [14/Sep/2010:18:10:17 -0400] "GET /api/1.0 HTTP/1.1" 301 0 "-" "-" 10.20.1.208 snowy.pyther.net - [14/Sep/2010:18:10:18 -0400] "GET /api/1.0/ HTTP/1.1" 200 276 "-" "-"
The 403 is happening during the OAuth process. From IRC: pyther: 10.20.1.208 snowy.pyther.net - [14/Sep/2010:18:06:29 -0400] "POST [3:22pm] pyther: /oauth/request_token/ HTTP/1.1" 403 2799 "-" "-" This is probably a csrf issue, shouldn't be too hard to fix, patches welcome of course.
You can fix this by adding @csrf_exempt decorators to oauth_request_token and oauth_access_token in lib/piston/authentication.py, but I'm not totally sure that's the correct approach. It certainly isn't done upstream. Relevant links: http://bitbucket.org/jespern/django-piston/issue/82/post-requests-fail-when-using-django-trunk http://groups.google.com/group/django-piston/msg/d8ec106e492dbf8d I've verified that unit tests pass, sync works, and notes can be viewed with Django 1.2 if you add those decorators or disable the csrf middleware.
Also of note, upstream added the patch seen in the first link some time back. Adopting that patch allows us to remove the csrf-related lines in api/urls.py.
After a little more investigation, it seems that in prencher's fork of django-piston (which will most likely become the official 0.3 soon), the oauth endpoints I mentioned in comment#2 have @csrf_exempt applied, so we could patch that in and it wouldn't be too bad. Still, I'm working on upgrading us to use tip of prencher's fork along with python-oauth2 1.2.1. You can read about how to upgrade in Thomas Johansson's mails from this thread: http://groups.google.com/group/django-piston/browse_thread/thread/abe961170e2b72ec/47b33123bc6119f9?lnk=raot The main problem I'm running into right now is that the new piston seems confused about how we have both an anonymous handler and an oauth-authenticated handler for /api/1.0/. It gets upset about not being able to generate an oauth.Request object from the initial anonymous request to that URL (at least I think that's what's up). Mostly this comment is just a note to myself to remind me where to look when next I look at this.
I did not upgrade us to the latest piston yet, but I did apply the fixes discussed in comment#2 and have tested on Fedora 12 with Django 1.2 and sqlite. I am closing this bug and opening a new one to track upgrading to latest piston.