[cheater]

Hello!
I've been using JDownloader for a while - I'm still learning it. I really like it, it seems like a great power tool that doesn't limit people in what it does.

I've tried downloading something off of Twitter today and that required my login cookies. The tutorial requires the use of a Firefox addon called "Flag Cookies".

The moment I installed it, my browser slowed down to a crawl. Rebooting didn't help. I must add that I'm a power user so i have a lot (LOT!) of windows open, but during normal operation my browser has immediate response and is very snappy. I think something in this addon has some sort of issue that requires it to constantly communicate with various tabs, and maybe there's some > O(n) behavior happening there. I had to disable it again.

Yes, I could start a new profile just for JD logins, but that's cumbersome. Also the usage story of the plugin itself isn't the best.

UX issues:

when I decided to log into Twitter, a dialog showed up that told me to enter the user name and password. I did that, and then a popup showed up with a confusing message:



"Cannot add Account because Enter cookies to login"

but eventually I also got a new tab in my browser opened with a support page. This page is a little cluttered so by the time it was time to take the cookies and enter them somewhere, my eyes kind of... glazed over and skipped step 4 and the rest. So I didn't know where to go to put the cookies in - it took some googling (which eventually put me on the same page) until I noticed that image with the red and blue rectangles that says to put the cookies string into the password box.

This whole experience is kind of overwhelming and kind of jank... it could be better.

The popup informing me I need cookies could be better than "Cannot add Account because Enter cookies to login". Maybe "Cannot add Account because you need to enter cookies in the password box to log in"? that's intelligible

Maybe a new dialog could be added where now i'm not entering cookies into a box called "password", but there's instead a box called "cookies".

But also the Flag Cookies addon is a problem.

I feel like the whole process could be easier if there was a dedicated JD addon for browsers. Instead of interacting with every which tab, I could just open a single tab with the plugin in action there. When the desktop JD app wants to log into a specific site, it could just ask the plugin to open the app in an invisible iframe, and then thanks to that, the addon now has the right context to load the cookies. The cookies never expire and no copy-pasting is necessary. And if you had such a tab open in multiple tab containers, then you could have multiple logins into a single site available at once. The addon could communicate with JD via a localhost https port that JD exposes. I don't know if JD already has a https rpc port - but I guess it probably does. When trying to log into a new app in the JD desktop app, it would just tell me to install the browser plugin, and once that's set up, it would tell me eg "Here are the logins for twitter that we detected in the browser: ..."

OK, I know that's a design that's a little complex maybe when you describe it - but I feel like the whole login situation in JDownloader could be greatly simplified in this way.

I do appreciate however the fact that copy pasting cookies manually is good for users who want to have absolute control over what they give JDownloader. They should still be able to do that, it's a good thing for them.

If anything, I hope the instructions can be updated to mention some other addon that can get cookies out of Firefox, because Flag Cookies is seriously unusable. I would appreciate suggestions for another addon.

[pspzockerscene]

Hi,

Originally Posted by cheater

The tutorial requires the use of a Firefox addon called "Flag Cookies".

That is not entirely correct.
The instructions let you choose between two addons: FlagCookies and EditThisCookie.

Originally Posted by cheater

The moment I installed it, my browser slowed down to a crawl. Rebooting didn't help. I must add that I'm a power user so i have a lot (LOT!) of windows open, but during normal operation my browser has immediate response and is very snappy. I think something in this addon has some sort of issue that requires it to constantly communicate with various tabs, and maybe there's some > O(n) behavior happening there. I had to disable it again.

I can't confirm this.
Please report it to the official developer of the open source addon:
ngb.to/threads/addon-ff-gc-o-e-flagcookies.32496/
Alternatively use the "Support" tab in the addon store (if also available for Firefox users).
So far the FlagCookies developer responded super fast to all issues I've reported.

Originally Posted by cheater

"Cannot add Account because Enter cookies to login"

but eventually I also got a new tab in my browser opened with a support page. This page is a little cluttered so by the time it was time to take the cookies and enter them somewhere, my eyes kind of... glazed over and skipped step 4 and the rest. So I didn't know where to go to put the cookies in - it took some googling (which eventually put me on the same page) until I noticed that image with the red and blue rectangles that says to put the cookies string into the password box.

This whole experience is kind of overwhelming and kind of jank... it could be better.

We are currently working on changing the UI for cookie supported logins.
This requires some more refactoring so it will take more time (no ETA given!).

Originally Posted by cheater

The popup informing me I need cookies could be better than "Cannot add Account because Enter cookies to login". Maybe "Cannot add Account because you need to enter cookies in the password box to log in"? that's intelligible
Maybe a new dialog could be added where now i'm not entering cookies into a box called "password", but there's instead a box called "cookies".

That will be improved once said changes are done.

Originally Posted by cheater

I feel like the whole process could be easier if there was a dedicated JD addon for browsers. Instead of interacting with every which tab, I could just open a single tab with the plugin in action there. When the desktop JD app wants to log into a specific site, it could just ask the plugin to open the app in an invisible iframe, and then thanks to that, the addon now has the right context to load the cookies. The cookies never expire and no copy-pasting is necessary. And if you had such a tab open in multiple tab containers, then you could have multiple logins into a single site available at once. The addon could communicate with JD via a localhost https port that JD exposes. I don't know if JD already has a https rpc port - but I guess it probably does. When trying to log into a new app in the JD desktop app, it would just tell me to install the browser plugin, and once that's set up, it would tell me eg "Here are the logins for twitter that we detected in the browser: ..."

Yes usability wise this would be nicer but we are not going to do that:
The user should decide which cookies he wants to add to JD and which not.
We do not want to have an official browser addon with the functionality of just grabbing the users' cookies.

Originally Posted by cheater

If anything, I hope the instructions can be updated to mention some other addon that can get cookies out of Firefox, because Flag Cookies is seriously unusable. I would appreciate suggestions for another addon.

I urge you to contact the FlagCookies developer as my experience with that addon is a completely different one.
That said, as explained, you may as well just use "EditThisCookie" instead.

Originally Posted by cheater

OK, I know that's a design that's a little complex maybe when you describe it - but I feel like the whole login situation in JDownloader could be greatly simplified in this way.

Keep in mind that JD is an application with a significant historical growth.
Back then there was only "username and password".
Now there can be:
- Username/Email and password (or similar)
- API-Key only
- Cookies
- Username and password or cookies (See "Type/Features") column in "Add account dialog"

Internal support ticket(s) regarding your requested GUI changes for easier cookie login process:



EDIT

I may add that JD is open source so you are more than welcome to contribute your own code changes.

[cheater]

Hi, thanks for taking this report seriously. A few things that I wanted to say.

Please report it to the official developer of the open source addon:
ngb.to/threads/addon-ff-gc-o-e-flagcookies.32496/

Of course, I know this can be done. But I wanted to alert you to this issue so that you can consider not recommending this addon any more.

BTW bear in mind EditThisCookie isn't also an option, because it isn't made for Firefox.

Yes usability wise this would be nicer but we are not going to do that:
The user should decide which cookies he wants to add to JD and which not.

This can still be done, of course. First of all, the users could still manually copy cookies over. Second of all, using the workflow I suggest, I didn't get into every tiny step of it, but it was clear to me that the users should be asked: "do you want to use the login cookies from the browser for abcdef.examplewebsite? yes/no". In fact I briefly describe a user interface that lets you select the cookie - you could then cancel out of it. And JD wouldn't receive any cookies from the browser until it explicitly requests them.

It's really all a matter of trust, I mean how do I know that JD doesn't just take my twitter login and leak it to someone in Russia? There's svn sources, but the build doesn't have to be based off of them, etc etc. As long as the users trust is respected, they will feel safe.

Personally I would strongly prefer an official JD addon for Firefox because that comes from the same place as JD. So for a user that already trusts JD, they'll trust the addon. I don't need to start trusting the developer of Flag Cookies. And on the other hand, if i'm the distrusting type, then: I can assume that if I run JD on my desktop, it's going to have more access to everything than an FF addon, so if I'm already running JD, then running the FF addon won't add to my threat exposure.

Yep, I understand JD is a very old codebase. It's doing very well for something that's existed for this long. Sometimes you have to take a look at some portion and go "ok, this part is now noticeably worse than the rest" and talk about it. That's all, it doesn't mean I think JD is bad or anything, I like it all in all. It has its idiosyncracies of which I wish there were less, but in general it's a very nice tool and I applaud people for sticking with the development for this long...

I'm already considering adding some code changes as time progresses. I've got it checked out in SVN already.

Maybe a warning could be added to the support page that says don't instal Flag Cookies if you have > 5000 tabs open? And instead suggest a piece of javascript to put in the console? I can't check right now what Flag Cookies exactly does, because I uninstalled it, but doesn't it just give you the contents of document.cookie?

[pspzockerscene]

Originally Posted by cheater

Of course, I know this can be done. But I wanted to alert you to this issue so that you can consider not recommending this addon any more.

BTW bear in mind EditThisCookie isn't also an option, because it isn't made for Firefox.

In my opinion this should be done since at this moment, if we'd remove FlagCookies from our instructions, there would be no addon for Firefox anymore. This would leave our instructions incomplete.
I can't reproduce your issues under Firefox so I do not see a reason to remove the references for this addon.

Originally Posted by cheater

This can still be done, of course. First of all, the users could still manually copy cookies over. Second of all, using the workflow I suggest, I didn't get into every tiny step of it, but it was clear to me that the users should be asked: "do you want to use the login cookies from the browser for abcdef.examplewebsite? yes/no". In fact I briefly describe a user interface that lets you select the cookie - you could then cancel out of it. And JD wouldn't receive any cookies from the browser until it explicitly requests them.

Understood.
As you can see a ticket for this exists since...10 years so please do not expect us to work on this any time soon.
I got your point but you need to get mine too:
Work on JDownloader can easily keep 3+ people busy 8 hours per day at this moment without doing major changes.

Originally Posted by cheater

Personally I would strongly prefer an official JD addon for Firefox because that comes from the same place as JD.

I can understand this partly: It would make things simpler but still:
The addons we recommended are both open source so I really don't see a [security-] problem with linking them.

Originally Posted by cheater

I'm already considering adding some code changes as time progresses. I've got it checked out in SVN already.

Nice

Originally Posted by cheater

Maybe a warning could be added to the support page that says don't instal Flag Cookies if you have > 5000 tabs open? And instead suggest a piece of javascript to put in the console? I can't check right now what Flag Cookies exactly does, because I uninstalled it, but doesn't it just give you the contents of document.cookie?

I don't agree:
Like JD, FlagCookies is also a piece of open source software.
The developer of it cannot fix a bug which he is not aware of and I do not want to report a bug to him which I cannot reproduce.
Just report the bug to him so at least he has the chance to fix it.
I mean you also wouldn't just abandon JDownloader due to bad usability: Instead you're reporting it to us.
EDIT

I may add: You can contact the FlagCookies developer via: ngb.to forum and github issues. Probably email is also an option.

[pspzockerscene]

Looks like you did contact the FlagCookies developer.
He has released a new version.
Changes:
github.com/jrie/flagCookies/commit/8b97d95b33be7b9bbbbc39641ef286469e989d7c

I've never encountered the bug and I'm not using Firefox so I'm unable to tell if his changes have addressed the issues you've reported.

[pspzockerscene]

I've just updated our cookie login instructions to link one more alternative:
The open source addon Cookie-Editor: github.com/Moustachauve/cookie-editor

Reasons for this include:

• EditThisCookie is not under active development anymore so it could stop working at any time when new browser updates get released
• It is using the same cookie export format which EditThisCookie is using
• It's always good to have alternatives

In the meanwhile, the FlagCookies developer looks to be working on an update which is supposed to fix the issues you've reported.

[cheater]

Originally Posted by pspzockerscene

I've just updated our **External links are only visible to Support Staff**... to link one more alternative:
The open source addon Cookie-Editor: github.com/Moustachauve/cookie-editor

Reasons for this include:

• EditThisCookie is not under active development anymore so it could stop working at any time when new browser updates get released
• It is using the same cookie export format which EditThisCookie is using
• It's always good to have alternatives

In the meanwhile, the FlagCookies developer looks to be working on an update which is supposed to fix the issues you've reported.

The performance of flagCookies has been fixed, however, its output now can't log JDownloader into instagram. My guess is during the refactor something broke and some of the cookies aren't being captured.

It's good that you added support for Cookie-editor, because now this can be used to log in.

However, this reinforces the idea that JD should have its own browser addon, which can feed JD fresh cookies any time the user requests them to be given to JD. (or personally I'd just set it to auto because i don't care)

This also has another implication.

Currently it's easy for JD to trigger web scraping protection in Instagram. It detects it and eventually, after it gave you enough warnings, you get banned from the site.

In fact, the JD browser addon could work in "passive mode" to spider the site: as you browse the website, the JD addon could gather media to download, rather than have the JD desktop app spider it on its own. Then, once you go to the Link Grabber and put in say the instagram account for Olaf Scholz, you can click a checkbox that's called "passive scan (only URLs already gathered by web browser addon)". Then you get all the Olaf Scholz photos the plugin has seen you look at, and it can likely download them without presenting the cookies (cookies should only be shown if a 404 happens, eg because you are friends with a private account). In fact, it could possibly even request those files from the browser's cache, and this way Instagram would be none the wiser. So unless Instagram completely disable the ability to browse their website from the web, they have no way of blocking that method. And I get all the cutest photos of Scholzi. Everybody is happy.

[pspzockerscene]

Originally Posted by cheater

The performance of flagCookies has been fixed, however, its output now can't log JDownloader into instagram. My guess is during the refactor something broke and some of the cookies aren't being captured.

Works fine here with the current version from github but I was able to reproduce the issue once with the older version.
Looks like that FlagCookies developer is already working on it.
Github issue as a reference for other users who might be watching this thread:
github.com/jrie/flagCookies/issues/3#issuecomment-1807168749

Originally Posted by cheater

It's good that you added support for Cookie-editor, because now this can be used to log in.

Cookie-Editor is just using the same format as the other addon "EditThisCookie" which we supported already so adding support for it was trivial.

Originally Posted by cheater

However, this reinforces the idea that JD should have its own browser addon, which can feed JD fresh cookies any time the user requests them to be given to JD. (or personally I'd just set it to auto because i don't care)

Well our myjdownloader addon could easily do this but development has stalled and we do not have a webdeveloper to maintain it at this moment.
You can find more information about the myjdownloader development situation in other threads of our supportforum.

Originally Posted by cheater

Currently it's easy for JD to trigger web scraping protection in Instagram. It detects it and eventually, after it gave you enough warnings, you get banned from the site.
In fact, the JD browser addon could work in "passive mode"[...]

You won't like my answer:
I'm sorry but we are not planning to put more time into this specific "cat & mouse game".
Instagram is fighting especially hard against bots.
Such "cat & mouse games" are usually very time intensive and ultimately, if you build a public software which can avoid the bot detection in a good way, the more users are using your software the higher the chances are that IG will add more and more changes which will take more time to implement and so on.

We did explain this already multiple times for example here:
https://board.jdownloader.org/showthread.php?t=92962
TL;DR
- Use the existing settings our IG plugin provides to try to avoid account bans
- If you need to download more items from IG, use tools psecifically designed to download from IG

And of course:
JDownloader is open source so you are free to add new features at any time.

And before you mention it:
Sure your idea could also be helpful for other websites which tend to block bots (such as Tiktok) but all in all, the 2nd part of your last post (and my reply) was specifically about Instagram.

[pspzockerscene]

Offtopic:
The FlagCookies developer is asking for a donation in his addon at this moment.
To increase the chances of this happening I'm willing to post his donation demand here too.
The following is auto translated from German to English:

Hello!
Thank you for installing FlagCookies. FlagCookies is a 'hobby project' and open source, free software.
I don't earn any money from my work on FlagCookies, but I would like to start an appeal that is very close to my heart.
My m other has to move out of our parents' house because of an unregulated inheritance. from the house that my m other renovated herself and moved into with little financial resources.
Also the house where my brother and I grew up.
If each of you gave just a small contribution, it would help my m other and us a lot. Even an amount of €1 would be a gesture of sympathy.
To donate, you can PayPal me at: paypal.me/dwroxnet
Anyone who donates can, if they wish, be mentioned by name on this donation page in FlagCookies. Please write an e-mail to jan@dwrox.net with the PayPal payment information, so that I can assign this.

Many many thanks
Jan

German version as screenshot:

[pspzockerscene]

Regarding my post #2:
The following changes have been done- and are already available for testing in our dev version:

• Updated login dialog for cookie supported- and "cookie-only" providers
• Added input validation and visual feedback for both login fields e.g. if only cookie login is supported you cannot enter anything non-cookie related into the password field
• Added errorhandling for when a plugin is switched from normal "user + password" login to cookie-only login and cookies are missing
• If user enters invalid data over our myjdownloader interface, detailed feedback will be provided there as well

Additionally I've also been working on a new generalized dialog for API key login based websites such as "cocoleech.com" and "nexusmods.com".

Screenshot: