Log in with different cookie than normal browser user? about nas-download-manager HOT 7 CLOSED

This is very strange. The extension specifically does not use cookies, but instead holds onto a unique session ID granted by DSM to hand back with requests. I'm not sure by what mechanism it would be leaking across into your normal browsing state, if that's what it's doing.

I followed your three steps above, including removing the extension entirely to start with a blank slate, and I wasn't able to see the behavior on Firefox 56.0.2. What browser version and DSM version are you on? Are you able to get it to happen reliably with the steps outlined above with no other intervening actions?

from nas-download-manager.

from nas-download-manager.

Alright, I got a repro working, but unsure how minimal it is. Steps:

1. Disable all my addons and remove Synology Download Manager.
2. Restart Firefox to ensure a clean slate w/r/t the addons.
3. In Firefox's preferences, always allow third-party cookies (no idea if this would make a difference, but it's caused weird problems around sessions for me in the past).
4. Log into DSM using the external URL I have setup through Synology (i.e., example.synology.me) with some user A, being sure to "Stay signed in".
5. Close the tab I'm logged into DSM with.
6. Install the Synology Download Manager addon.
7. Set up the addon with some user B (who has fewer permissions than user A, fwiw).
8. Hit "Test Connection".
9. Open DSM again in a new tab.

Now I'm logged out. Weird.

from nas-download-manager.

The above repro still works (i.e. breaks) with the latest version on master too. If I drop the part of the login test where it logs outs after itself, it just ends up hijacking the session, but leaving it logged in.

This is also happening with SynoLoader and SynoNext (other Firefox extensions). Synology Download Extender and SynoExt just didn't work on my install.

Upon further research, the key actually appears to be "allow third-party cookies". My suspicions are borne out! DSM sends back cookies even if we don't ask for them, and Firefox will apparently happily set the cookie for that domain even though the request is originating from an extension. That... seems like a bug?

The Synology is also at fault, since according to the docs it shouldn't be setting cookies if we ask for an sid instead:

Returned format of session ID. Following are the two possible options and the default value is cookie.

cookie: The login session ID will be set to cookie.

sid: The login sid will only be returned as response json data and the cookie will not be set.

@elisimpson could you try setting Firefox's "accept third-party cookies" setting to "never" and seeing if you still have the issue?

from nas-download-manager.

Should be fixed on master using undocumented APIs (spooky!). Look for the release in the coming days.

from nas-download-manager.

from nas-download-manager.

Of course!

For my own future reference: this is a known issue that using a higher version of the auth APIs don't have. Those newer versions are not documented, and after asking Synology support where I could find the docs for what changed between API versions and what's current, I got the response (paraphrasing) "i dunno lol" which isn't entirely helpful...

from nas-download-manager.