elmotheelk Posted January 8, 2010 Report Share Posted January 8, 2010 For my application Transdroid (for Android devices) I use the web UI's JSON RPC. Now everything works fine for 1.8.x and since I added token auth support uTorrent 2.0 works fine as well.However, I have problems connecting to uTorrent 2.1's web UI. I know this is ALPHA, but still... Getting the token works fine. It returns the (hidden) HTML and I get the token to construct this GET request:http://192.168.1.21:8810/gui/?token=gkqjnKJ0DsXISNLPpSJDbNRVoIfOzEnqQJqaTZ-XnJWRdNgVhlLi7koBR0s=&list=1(of course again with proper credentials)which has the response 'invalid request'.It works perfectly fine for uTorrent 1.8.x and 2.0. Also, logging in to and using the web UI itself from my browser works fine. Any ideas? Link to comment Share on other sites More sharing options...
Ultima Posted January 9, 2010 Report Share Posted January 9, 2010 Don't know what to say. I have no problems using the WebUI backend with external applications in µTorrent 2.1.Have you tried sniffing the packets to see if there's anything suspicious going on? Link to comment Share on other sites More sharing options...
Lord Alderaan Posted January 11, 2010 Report Share Posted January 11, 2010 Maybe try putting the token=blah at the end of the request. As in ?list=1&token=abcdefg Link to comment Share on other sites More sharing options...
elmotheelk Posted January 11, 2010 Author Report Share Posted January 11, 2010 I tried putting the token in the url after the list=1, but that didn't work.I tried to disable token auth temporarily in uTorrent 2.1 and in my app, and everything worked again as expected. So it sure has to do with the token.Next, I did the following experiment: Open a new browser (no cookie) and go to http://localhost:8080/gui/token.html This requires me to enter the credentials. View the source, copy the token and use it to go to http://localhost:8080/gui/?token=7vK5Bxy6ds7FLG5b_KTleUSp6ZCUT3TFZx5CwZp0vhoDg1hpueRnZqNKS0s=&list=1This returns a valid JSON string... Link to comment Share on other sites More sharing options...
Ultima Posted January 11, 2010 Report Share Posted January 11, 2010 Order of the GET parameters barely matter. And er, WebUI already puts token before list anyway, without issue.I must ask again, have you tried sniffing the packets to see what's gong on? Could it be that the Android is just caching requests very heavily (including token.html)? Indeed, it doesn't make sense that it's happening only for 2.1, but maybe it's sending slightly different header values that cause the Android to react differently, or something. Link to comment Share on other sites More sharing options...
Lord Alderaan Posted January 12, 2010 Report Share Posted January 12, 2010 The invalid request error is very specific and only as a few causes. We can be almost sure that in this case µtorrent isn't accepting the token you are supplying. So something must be going wrong there. Maybe you are adding some hidden character or are encoding improperly.Like Ultima said: Use a packet sniffer so you can see exactly how the http header looks of the request your app is sending to µtorrent when it tries to retrieve the torrent list. Or if you can't at least enable the logging of webui requests in the r-click menu of the logger tab in µTorrent. Link to comment Share on other sites More sharing options...
elmotheelk Posted January 12, 2010 Author Report Share Posted January 12, 2010 Thanks for both your responses.I tried using uRemote (the .NET GUI) and it wasn't able to connect as well. Also, it is persistent on all my systems (Ubuntu/Wine and Vista). I use uTorrent 2.1 build 17687 for testing.I used tcpdump to snif the packages. Here are the relevant headers (I removed the 0-length packages). Hope you don't mind me pasting those here.erickok@zwaag:~$ sudo tcpdump -i lo -A -s10000 port 8080[sudo] password for erickok: tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on lo, link-type EN10MB (Ethernet), capture size 10000 bytes13:44:07.820381 IP zwaag.cs.uu.nl.38856 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:84, ack 1, win 257, options [nop,nop,TS val 9471689 ecr 9471676], length 83........GET /gui/token.html HTTP/1.1Host: 131.211.81.197:8080Connection: Keep-Alive13:44:07.820533 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38856: Flags [P.], seq 1:160, ack 84, win 256, options [nop,nop,TS val 9471689 ecr 9471689], length 159........HTTP/1.1 401 UnauthorizedConnection: closeContent-Length: 0Content-Type: text/htmlCache-Control: no-cacheWWW-Authenticate: Basic realm="uTorrent"13:44:08.030435 IP zwaag.cs.uu.nl.38857 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:123, ack 1, win 257, options [nop,nop,TS val 9471709 ecr 9471698], length 122........GET /gui/token.html HTTP/1.1Host: 131.211.81.197:8080Connection: Keep-AliveAuthorization: Basic ZXJpYzpDbGlvMTcy13:44:08.032746 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38857: Flags [P.], seq 1:279, ack 123, win 256, options [nop,nop,TS val 9471710 ecr 9471709], length 278........HTTP/1.1 200 OKConnection: keep-aliveContent-Length: 117Content-Type: text/htmlSet-Cookie: GUID=XVMGOIut0hCTJhy7f41W; path=/Cache-Control: no-cache<html><div id='token' style='display:none;'>y7JZRxL_9LGARKLWlHr0zb6A0l5ez-R5deT6b9Q_YwxeshhKpFQBqZhuTEs=</div></html>13:44:08.360571 IP zwaag.cs.uu.nl.38858 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:148, ack 1, win 257, options [nop,nop,TS val 9471743 ecr 9471730], length 147........GET /gui/?token=y7JZRxL_9LGARKLWlHr0zb6A0l5ez-R5deT6b9Q_YwxeshhKpFQBqZhuTEs=&list=1 HTTP/1.1Host: 131.211.81.197:8080Connection: Keep-Alive13:44:08.362012 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38858: Flags [P.], seq 1:160, ack 148, win 265, options [nop,nop,TS val 9471743 ecr 9471743], length 159........HTTP/1.1 401 UnauthorizedConnection: closeContent-Length: 0Content-Type: text/htmlCache-Control: no-cacheWWW-Authenticate: Basic realm="uTorrent"13:44:08.578290 IP zwaag.cs.uu.nl.38859 > zwaag.cs.uu.nl.http-alt: Flags [P.], seq 1:187, ack 1, win 257, options [nop,nop,TS val 9471764 ecr 9471753], length 186....... GET /gui/?token=y7JZRxL_9LGARKLWlHr0zb6A0l5ez-R5deT6b9Q_YwxeshhKpFQBqZhuTEs=&list=1 HTTP/1.1Host: 131.211.81.197:8080Connection: Keep-AliveAuthorization: Basic ZXJpYzpDbGlvMTcy13:44:08.579744 IP zwaag.cs.uu.nl.http-alt > zwaag.cs.uu.nl.38859: Flags [P.], seq 1:154, ack 187, win 265, options [nop,nop,TS val 9471764 ecr 9471764], length 153........HTTP/1.1 400 ERRORConnection: keep-aliveContent-Length: 15Content-Type: text/htmlSet-Cookie: GUID=rjRBmFXS5ZuTfUiF1Fgu; path=/invalid request^C40 packets captured80 packets received by filter0 packets dropped by kernelerickok@zwaag:~$ It seems to me that authentication is denied and, when a retry is send, the 'invalid request' is responded to me.I use the Java Apache HTTP client that is part of the default Android SDK. This, afaik, doesn't cache pages but it does automatically handle cookies, for example.Thanks for the help so far. Link to comment Share on other sites More sharing options...
Ultima Posted January 12, 2010 Report Share Posted January 12, 2010 Hrm. From my own packet sniffs, it does indeed seem like µTorrent v2.1 is sending different request headers, and even different error codes.In the past, when it responded with "invalid request", it would return it with a HTTP 300 (which, frankly, isn't even the correct status code, and probably should never have been mentioned/described in the original specifications for token authentication in the first place). Now, µTorrent is correctly returning HTTP 400. I'm not sure if your existing code is reliant on detecting HTTP 300 before deciding to grab a new token, but if so, you might want to change it (checking that the status != 200 and maybe parsing the request body might be a better idea, since AFAIK ony HTTP 200 is sent with successful requests).As an aside, it seems like µRemote is also trying to detect HTTP 300 as an indicator that a token is required, because after it receives the HTTP 400, it never bothers to request /gui/token.html. Unfortunately, matias has put µRemote development on indefinite hiatus... hopefully he can come back just to fix this bug.Other than that, µTorrent v2.1 also sets HTTP cookies now, presumably to better support multiple sessions. I doubt that makes a difference though.When I said I tested an external application without issue with µTorrent v2.1, I was referring to µTorrent Adder. It works fine still, and indeed when I was writing it, I made sure to test that the HTTP status wasn't 200 instead of checking specifically for HTTP 300.Edit: Ugh, what I wrote is nice and all, but it doesn't seem relevant to your situation, based on your packet sniffs, since you are actively requesting token.html... Only µRemote isn't requesting token.html on error :/ Basically, it looks to me like µRemote's problem is unrelated to yours. So uh, I'm at a loss for ideas right now. Link to comment Share on other sites More sharing options...
Lord Alderaan Posted January 12, 2010 Report Share Posted January 12, 2010 Hmmz, it looks pretty good.What I see is:1) you get token.html but get unauthorized2) so you get token.html with auth info and get token3) then you get the list with token but without auth info and get unauthorized4) so you get the list with token and auth info but now you get invalid requestNow the only thing that is actually wrong here is that normally one would supply the auth info at step 3. It is possibly the token got invalidated because it was used without proper auth info.I never ran into this issue before but then again browsers keep sending the auth info after it has been accepted once (which is why you actually need to close all browser windows to logout of the webui). Link to comment Share on other sites More sharing options...
elmotheelk Posted February 11, 2010 Author Report Share Posted February 11, 2010 Thanks for your time and replies. This problem is now fixed and indeed it was due to the changes in 2.1. In particular the binding between token and cookie, as explained in http://forum.utorrent.com/viewtopic.php?id=58111By the way; Transdroid now support token authentication. Would be nice to update this in the Web API app list. Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.