search

kyuucr / add-link-to-qbittorrent-webui

Firefox extension for adding torrent link directly to qBittorrent WebUI from context menu.
MIT License
20 stars 0 forks source link

Possibility to use authentication method other than third-party cookie #7

Open simonbcn opened 5 years ago

simonbcn commented 5 years ago 
Arch Linux
Firefox 67.0.4
"Add Link to qBittorrent WebUI" v5

My "Content Blocking" configuration:

captura_20190701_182145

My configuration for WebUI qBittorrent:

captura_20190701_182336

captura_20190701_182913

But your extension insists on saying it can't find the credentials (the access to the webUI is passwordless):

captura_20190701_182434

The cookies configuration in last Firefox versions is more complex than explained in current README.md.

Why is access to that cookie necessary if access to the webUI is without a password? Couldn't the webUI user/password fields be added to the extension configuration to avoid this?

simonbcn commented 5 years ago

I've tested with "Content Blocking" to "Standard" and fails too.

kyuucr commented 5 years ago

I used FF 67.0.4 on Windows 10 May 2019 update and qBittorrent-nox v4.0.3, I tried to replicate your content blocking setting and it still works for me. Is it possible that the problem is not the content blocking setting?

Why is access to that cookie necessary if access to the webUI is without a password? Couldn't the webUI user/password fields be added to the extension configuration to avoid this?

Yes, but since we will have multiple different webUI site based on the profile, this going to make the addon save multiple username and password (and becoming a password manager). I don't trust myself to write a code that can store credentials safely, therefore I went with this approach.

I have considered implementing a proxy request to a tab containing the webUI (similar to another torrent addon), but haven't got the time to think about it.

simonbcn commented 5 years ago

I've tested it in a new empty profile without any extension and all settings to default. After entering qBittorrent webUI (localhost:8080), I can see the cookie in the list:

captura_20190702_121518

I restart Firefox and I see again the cookies list without entering qBittorrent webUI:

captura_20190702_121550

The localhost cookie is deleted when I close Firefox.

simonbcn commented 5 years ago

This is my qBittorrent webUI configuration (I have changed the port):

captura_20190702_123900

kyuucr commented 5 years ago

So it is not addon's fault and it's something to do with FF not saving your cookies? Did you check if there's anything that can delete your cookies on restart? Also, try to disable webUI authentication bypass for localhost?

simonbcn commented 5 years ago

I've tried to disable webUI authentication bypass for localhost and same problem. I don't know what the problem is but Firefox remains others cookies like authentication cookies.

simonbcn commented 5 years ago

This is a very annoying issue. I have to open the webUI to this extension works. I think relying on cookies created by another application is a very bad idea, especially if it interferes with the browser's security settings. Can't access the Firefox password manager to save the password? In any case, I have inspected the cookie created by qBittorrent webUI and specially the Expires setting: captura_20190710_100906

simonbcn commented 5 years ago

The rule is that session cookies are deleted when you close your browser but there is one exception to this ( More info: http://blog.petersondave.com/cookies/Session-Cookies-in-Chrome-Firefox-and-Sitecore/ ):

Similar to Chrome’s start-up feature, Firefox Session cookies are also saved to allow for Firefox’s session restore feature. If the browser is forcibly closed or crashes, session cookies are not deleted and the session remains. It’s worth noting, this does not happen on sites backed by https. While this is default behavior, unlike Chrome, closing the browser will clear any session cookies present.

kyuucr commented 5 years ago

This is a very annoying issue. I have to open the webUI to this extension works.

Yes, this is how the extension works from the start, currently I have no plan to change it.

Can't access the Firefox password manager to save the password?

The old SDK addon can access them, and they're still working on the login API for webextensions (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1324919). It might be a good idea to implement it when it's done, but judging from the comments it may take a longer time.

kyuucr commented 5 years ago

Content blocking setting

Apparently this setting actually blocks the addons from working, but it needs Firefox restarted after applying the setting, possibly because the cookie setting only applied to the addon when it's loaded (i.e., Firefox restart).

simonbcn commented 5 years ago

I've tried with Content Blocking = Standard and it fails too.

kyuucr commented 5 years ago

I've tried with Content Blocking = Standard and it fails too.

Have you tried restarting Firefox? and by restarting I mean really check if the process stopped and then start it again. I had the same problem and found out when the process still lingers in background, the addon still broke.

simonbcn commented 5 years ago

When I close Firefox (in Linux), all "Firefox" processes are closed. On the other hand, if the process did not stop, the session cookie would not be deleted. See this Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=443354#c1

A session cookie is deleted when the session ends and/or the browser closes (without "session restore" activated). I don't think it's a matter of "Content Blocking" of Firefox. If you take a good look, Content Blocking prevents the creation of cookies but it doesn't prevent the extension from reading it. So I don't think this is the problem.

The problem is that this extension depends on a session cookie. So you have to open the webUI before you can use this extension, which in my opinion is annoying. Also when I send a torrent through this extension and the cookie does not exist, the extension opens the webUI (for the cookie to be created) but does not retry sending the lost torrent.

kyuucr commented 5 years ago

Oh, yeah I agree, this is already a different topic. As I already said, the behavior of the addon when cookie expired by any means (e.g., session or date expiry) is working as intended (for now). I was confused back then when I used your content blocking configuration but still able to use the addon normally, turns out the setting only applies to the addon after FF restarts. So for now, discussion about the content blocking setting is done.

Now, let's keep the discussion around the possibility of ditching third-party cookie. For now, I am thinking to just wait for the login API to be implemented, since it is the safest way to implement it.