Archived

This topic is now archived and is closed to further replies.

Ultima

µTorrent WebUI

Recommended Posts

@phunkyfish: What do you mean by "blank"? Is it completely blank with nothing, or are the fields just not filled in at all...? Screenshot?

@joz: That doesn't make any sense. WebUI has always requested using /gui/, and the onus has always been on the URL rewriter to rewrite any and all requests for /gui/ to the proper location. If it isn't rewriting it now -- and especially only for token.html -- then chances are, somethng isn't set up properly on your end. It makes even less sense that regular requests are working for you, but just requesting token.html isn't. You'll notice in the request you observed, WebUI is requesting everything from the same base location. Anyway, browsers apply the login to the domain, so as long as the application is not making a request outside of that domain (which it isn't -- and can't, due to XHR security limitations), then there should be no reason the browser wouldn't properly send the auth header in the request, even if it's trying to request from a different directory. Unless of course the rewriter isn't rewriting all requests, such that the token request is hitting the wrong location on your server.

Yes, WebUI never used to request token.html unless it was logged in as guest, and that changed with the latest release of v0.362, but that should never be a reason it should fail now. More and more, I'm thinking that it's a problem in your URL rewriting rules.

FYI, I asked Lord Alderaan to test URL rewriting with v0.362 on his Apache server a few hours ago, and he didn't seem to have any such problems with basic HTTP auth failing. Have you tried clearing your browser cache and such like I asked you before? Additionally, it would be helpful if you included a log of some of the requests (working and non-working), and maybe the relevant parts of your Apache configuration that's doing the URL rewriting.

Share this post


Link to post
Share on other sites

Couldn't you add "completed on" please? I'm curious why WebUI was made without that in the first place. Without the "completed on" the completed page is kinda useless if you have a few hundred completed torrents.

Share this post


Link to post
Share on other sites

Happy new year!

Ultima I get your point and I truly want to believe everything you say but it's just what it is (at least to me).

If I put the updated webui.zip in there it does what I desrcibe, if I then replace it with the version before, it does not.

So yeah it might still be something on my side but then it's something that has worked (although luckily, maybe) with my config with the older versions.

Sorry I do not know what to tell you or how to help you with this (it might not seem like it but I really would ;)). I guess I'll just stick with the prev. version then. Thanks again for all the hard work!

----EDIT----

FYI, I asked Lord Alderaan to test URL rewriting with v0.362 on his Apache server a few hours ago, and he didn't seem to have any such problems with basic HTTP auth failing. Have you tried clearing your browser cache and such like I asked you before? Additionally, it would be helpful if you included a log of some of the requests (working and non-working), and maybe the relevant parts of your Apache configuration that's doing the URL rewriting.

I did clear cache, cookies etc with FF webdeveloper, I kinda have to cause I eventually have this running in an iframe (the discussion before :) IE quirkness :P) and that's kinda cache persistent in many ways in FF (I have been testing without iframe so that should not mather).

I will try and get you the logs today (and analyze them myself ofcourse), I guess you mean apache access logs right? Or is utorrent doing some logging on this aspect.

I have not investigated it that far, kinda busy, you know how it is.

----EDIT2---

Ok I could offer you this, but just if you're willing and I understand if you're not.

The PC in question, running utorrent/webui, is my server/htpc. It runs windows and I already have it setup to accept RDesktop connections from the outside.

So what I could offer you is guest access to this system (I think you are most likely an ok person but just in case I'll create backups so I can easily go back). I could also switch a couple passwords around so you can test certain aspects.

Just if you're willing, if you're not I can understand and that's ok.

Share this post


Link to post
Share on other sites

On some torrents, Availability is clearly 0.999 and most peers are at 99.9, but WebUI shows Availability as 1.000, which is definitely WRONG.... Any ideas?

thanx...

Share this post


Link to post
Share on other sites

Will be fixed for the next release. The problem was that WebUI was dividing the availability by 65535, when it should have been dividing by 65536, because 65536 denotes 1.0 availability. Almost a rounding error, but more like just completely incorrect calculation :P Which reminds me, I'll need to correct the API docs, since it also states that the availability is sent in 1/65535ths.

@joz: Don't get me wrong, I'm not telling you that you absolutely aren't seeing this problem -- just that I can't reproduce it. Going back definitely isn't the optimal solution, because if there is indeed a problem in the way WebUI is sending requests, it'll never be fixed if we don't solve it now, and you'll be forever stuck using an old version.

Request logs from your browser (Firebug on Firefox or something, or maybe even Google Chrome's developer tools, which are actually very useful), request logs from Apache (and if logged, the rewritten requests too), and request logs from µTorrent itself (make sure you log only WebUI requests in the Logger tab's context menu). That way, we can see what's going wrong where.

Share this post


Link to post
Share on other sites
Couldn't you add "completed on" please? I'm curious why WebUI was made without that in the first place. Without the "completed on" the completed page is kinda useless if you have a few hundred completed torrents.

Oh! I need this so much!

Share this post


Link to post
Share on other sites
v0.362 WIP (2010-01-09)

+ Feature: #87 (Search bar needs a submission button)

~ Change: GUI update interval limited to a minimum of 500 ms

~ Change: Made more resilient to request errors (retry on failure)

* Fix: #42 (Bad behavior when unexpected 'torrents' list returned)

* Fix: #92 (Dividers can be dragged out of window and 'lost')

* Fix: Dirty selection tracking on listview sort

* Fix: Guest page not resizing with window

* Fix: Incorrect availability calculation

* Fix: Keyboard shortcuts for listviews not working on some browsers

* Fix: Not all torrents in label/category displayed when emptied and refilled

* Fix: Progress bar not shown on guest page

* Fix: Progress bar overflowing listviews in IE

* Fix: Regression in support for rewritten URLs

* Fix: Search button slightly misaligned in IE

* Fix: Selecting nothing in listview still registers as selecting an item

This build should hopefully solve the issue for users where WebUI simply stops updating at all for no good reason, since it will retry requests on failure now (before, whenever it encountered an error, it would stop updating). A bunch of polishing went into this release. I think I've ironed out most (if not all) of the most obvious bugs in WebUI, which should make this build almost ready to replace v0.361 as "stable." Will need to wait for feedback from users though, of course.

Divider positioning and control sizing on window resize was completely overhauled, so you will almost definitely need to reset the UI by pressing Esc.

Get it in the first post.

@joz (if you're even reading this): Although the changelog says "* Fix: Regression in support for rewritten URLs", I haven't changed anything with regards to URL rewriting since I gave you these patched files. I can't proceed until I have more information. And just FYI, if you're really having trouble getting me the logs, you can always change the urlBase variable in webui.js.gz to match your needs, and it'll work just fine.

Share this post


Link to post
Share on other sites

Hey ultima,

sorry I have not been of much help but I'm still here and not planning to give up on it. Just been a bit busy. I will start testing again with the latest, most likely in VM so I can start from scratch.

So i hope to atleast provide you with logs asap. Anyway thx again for this tool and not giving up on this user

Share this post


Link to post
Share on other sites

Hi Ultima, great work on the WebUI thus far! Seems you're right about it requiring Compatibility View in IE for resizing frames and menus to work, however it doesn't give me the option and I had to add it manually to the list. Isn't there a tag you can put in to force Compatibility View? I would highly recommend it before you release this as stable to the masses. Cheers.

Share this post


Link to post
Share on other sites
v0.362 WIP (2009-05-31)

~ Change: Force IE7 compatibility mode in IE8

And this is the relevant tag already included in index.html/guest.html since that build:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

IE8 doesn't show the compatibility mode toggle button in the toolbar because compatibility mode is already forced by the markup.

Share this post


Link to post
Share on other sites

Odd then, I was getting the problems with resizing frames and menus not disappearing once opened until I manually added it to the list.. IE is so unreliable hah.

Share this post


Link to post
Share on other sites

Not too sure if I can post this here, but lately, I realized that when I edit the Labels/Tabs for webUI, they don't seem to 'save'.

Because when I reload the page, it defaults back to the default settings as if I never edited it to look the way I want it to.

Share this post


Link to post
Share on other sites

I did a bit of testing again and I think I have found my issue.

For the time being I have been using url's with credentials in my server console (little project I have been doing), in the form of;

http://someuser:somepassword@someuri:someport/somedir

I know this is not supported by IE defaults, works for all other browsers though afaik.

This is the source of the problem in conjunction with my apache proxy rewriting.

It only is not working through apache proxy, this "url credential" method does work with direct calls to webui. The funny thing is that it used to work, like 2 versions back, no probs.

Sorry for all the fuzz and my lack of testing. I think this is too specific to be considered as a bug and I guess a pain in the ass to fix if at all possible (might actually still be something on apache's config side).

However I am still not about to give up and was wondering if Ultima's willing to share his opinion and point of view as a web developer!? Here's what I'm thinking (quote from mediaportal thread):

A lot of the third party web applications I use in my server console require a login to be accessed. This is a good practice and I do not want to disable any of it however requires loging in when accessing certain parts of the console (like ForTheRecord or utorrent for example). Which means for 4TR access thru server console I need to login to the console (or not when I have set remember me cookie) and then login to 4tr. You can guess were I'm going with this, circumventing the second (in this aspect unneccessary but still vital for security cause 4tr URL is still accessible with a direct URL).

So what I though of doing now since I have not been successfull with this totally yet (I have some half assed stuff going that works kinda). The scenario:

Apache runs on port 80,

ForTheRecord runs on 8080

When accessing it thru the server console I will be using the server as a proxy to itself (although on a different port)

So all requests done for 4TR will go to apache (say on "/4tr/request?org-url=http://fortherecord-original-url-request") which then fires a php script that uses cURL and the get paramater orig-url as the URL to cURL too. Bassically using a proxy call.

This way the first request (the login) will generate a cookie on 8080 (which is useless for port 80). That cookie will be send over and over for the proxy requests (from the server) which then will validate because they are on the same domain (read on the same port)

This method will then be used in conjuntion with inserting a <base> tag in the head to have all relative uri's point to the right location (read the php cURL script with param ?orig-url=$_SERVER['REQUEST_URI'])

This'll be a bit of work and testing to get to go, not started yet. I have this feeling there'll be a snag somewhere around the corner.

Share this post


Link to post
Share on other sites

Strange, I tried resetting webUI to default, with "esc", but it just hangs at "Reloading..."

EDIT:

Nothing shows up in the webUI Logger, but when I cehck my FireFox Error Console I get:

Error: [Exception... "An invalid or illegal string was specified"  code: "12" nsresult:
"0x8053000c (NS_ERROR_DOM_SYNTAX_ERR)" location: "file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/
modules/WindowsPreviewPerTab.jsm Line: 308"]
Source File: file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/modules/WindowsPreviewPerTab.jsm
Line: 308

Warning: Unknown property '-moz-opacity'. Declaration dropped.
Source File: http://##.###.###.###:8080/gui/stable.css
Line: 1

Warning: Unknown property 'zoom'. Declaration dropped.
Source File: http://##.###.###.###:8080/gui/main.css
Line: 1

Error: preview is undefined
Source File: file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/modules/WindowsPreviewPerTab.jsm
Line: 340

Error: this.preview is undefined
Source File: file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/modules/WindowsPreviewPerTab.jsm
Line: 349

It might possibly be due to me using FireFox 3.7a1pre, but not too sure.

Share this post


Link to post
Share on other sites

Works fine on my end with 3.6. And I don't know what you mean by editing labels/tabs.

@joz: If you're going to preprocess files before sending them to the browser, you might as well just unpack webui.js.gz, search and replace all instances of /gui with whatever path you want on-the-fly, and send the result along to the browser. Or uh, just edit webui.js.gz directly as I mentioned before...

Share this post


Link to post
Share on other sites

Strange....

Editing labels/tabs.

Resizing them / Disabling some of them (To not show)

Even when I try to edit the settings (Display speeds on Title Bar).

Once I reload the page, it doesn't save it and just defaults back.

Share this post


Link to post
Share on other sites

Hey ultima,

I was looking for something generic actually, webui is not the only one.

So I guess I'll just give it a shot when I have time.

Share this post


Link to post
Share on other sites

joz,

Maybe you should take a look at the code of the Webui Shell. Sadly trac is down atm so you can't. But the Webui Shell is a php app that kinda does what you want to do (except that it is a lot more complicated because of all the extra functionality).

Share this post


Link to post
Share on other sites

@SacredCultivator: If you happen to be using µTorrent 2.1, then there's your explanation. Apparently, µTorrent 2.1 completely removed webui.cookie, which is a core functionality in WebUI used for persistent storage of settings across browsers. By removing it, any attempt to set the cookie fails in µTorrent 2.1. Not a whole lot can be done about settings not being saved.

As for not reloading on Esc... the reason this has started happening is because the request to store webui.cookie fails now, so WebUI attempts to recover by resending the request (it can't tell the difference between an expired token and a rejected request because µTorrent returns the exact same error code/message in either situation, even though invalid tokens are recoverable problems while rejected requests aren't). Until the request goes through, it won't reload. In the current release, WebUI never stops retrying, which (frankly) is a bit dumb, but I was trying to get a basic framework out, so I just left it that way. I've already modified my local copy to stop retrying after a certain number of failures.

Share this post


Link to post
Share on other sites

^You're correct.

Switched over to 2.0 RC3 and problems were fixed.

FOr 2.1, when that goes 'official' so to speak, that will utilize Falcon and not WebUI correct?

Share this post


Link to post
Share on other sites

Wow didn't realize there was still development in the WebGUI. Great!

I was hoping for magnet links support :) and rss feeds/being able to edit the rss downloader and add/delete/modify feeds. I know uTorrent 2.1 can make this available for webgui. Since 2.1 isn't very stable yet it's not interesting for now. But I am willing to test :)

Share this post


Link to post
Share on other sites