Implementing authmanager to classic_mode startup...

[dasnyderx@…]

After pulling down and building the latest version from svn of deluge, I found that starting the app in classic_mode (without any configuration data present) caused the UI to appear, but not be completely instantiated. I was able to trace the problem down to the connectionmanager class and, more specifically, the get_localhost_auth_uri() method at line 159. The problem appears to be linked to the fact that, if the config-area file, 'auth', hadn't been created, then the get_localhost_auth_uri() will continually loop (which is bad). Therefore, the attached diff seeks to remedy this situation. More specifically, it seeks to take care of the three cases I thought were probable:
1) The 'auth' files doesn't exist and the UI is started in 'classic_mode'.
2) The 'auth' file exists, the UI is started in 'classic_mode', but the 'auth' file doesn't contain the 'localclient' username.
3) The 'auth' file exists, the UI is started in 'classic_mode', and the 'localclient' username exists.

Since the third case is clean sailing, I won't touch on it.

As regards the first case, the modification of the common file method, get_localhost_auth_uri(), sees if the 'auth' file exists, creates it if it doesn't (through a call to the authmanager start() method), and continues on. I also modified the URI string assemblage to make sure that the user is connecting from '127.0.0.1' (just to be on the safe side).

For the second case, I added the check of the returned URI in the connectionmanager so that, if the 'localclient' authorization wasn't found (i.e., the 'auth' file exists, but the username, 'localclient' isn't in it), the UI wouldn't just be left hanging forever (as happened with me) and would notify the user forthwith. Perhaps an exception isn't the best way to handle it (now that I think about it, perhaps an error message and app shutdown would have been better), but (from my standpoint) an exception is always the best way to get me attention. Also, you may want to make the same check within the 'autostart_localhost' block in order to guard against the UI hanging due to a faulty/missing 'auth' file (I didn't do this because it's late, and I'm tired).

BTW, if you should decide to keep the URI check with user notification of the problem (which I think would be good thing), you might want to put something up on the FAQ about how to fix it. That way, if the user should get the error-message, "Could not locate localclient authorization" (or a message like it), they would know how to fix it. Just my .02.

As before, the diff has been made against the latest svn code.

[dasnyderx@…]

Diff to the UI common and GTK UI connectionmanager files

[andar]

I don't think this patch is really correct.

First off, since this is the ui.common module, you do not want to import anything from deluge.core as it could break if people only install the UIs and it just goes against how things are naturally separated. That being said, I do have plans to implement a true classic mode where the daemon is not another process..

The while loop continues indefinitely if no auth file is found, which can be a problem.. I think the best solution is to just put a hard time limit on the loop and exit out with an error.

I did test the lastest revision with a clean config and it seemed to work fine, so I'm not too sure how you are encountering a problem with it?

[anonymous]

Milestone 1.1.0 deleted