#1
|
|||
|
|||
"Your 'My JDownloader' logins are not correct" - with NO changes
I've been having the same issue as reported here for a few days now. I've made NO changes to my config or login credentials, and the same credentials work fine to log into my.jdownloader.org from my web browser. I've logged out and back in multiple times to be sure.
I run JDownloader2 headless. I connect to the server with SSH, so you can rule out telnet copy & paste issues. I checked my org.jdownloader.api.myjdownloader.MyJDownloaderSettings.json and the credentials are correct there. They match my password manager, and I can copy them straight from the json into the browser and they work there. So I don't see how it can be any kind of hidden character/encoding problem. Plus, as I said, I hadn't touched the credentials in any way and they'd been working fine up to this point. When it prompts me to reenter them I've tried typing them in manually, just in case. Makes no difference. I've reentered them about ten times in a row just in case jd2 had multiple threads each trying to get the correct credentials, never helped. I tried renaming my /config directory and starting completely fresh, entering the credentials manually when prompted, they still don't work. I can't think what else to try. It really doesn't seem like the credentials themselves are the problem. It's very possible there's some other connectivity-related problem and your exception handling is just mis-identifying it as a credentials issue. But there's so much logging I just don't know where to look. |
#2
|
|||
|
|||
I just wiped everything and ran a fresh install, paused where it prompted me for credentials, truncated all the log files, and then entered the credentials. So this output should be only the immediate results of trying to log in:
UncaughtExceptionHandler.log.0: Code:
--ID:50TS:1672678089577-1/2/23 11:48:09 AM - [jd.SecondLevelLaunch$4(uncaughtException)] -> Uncaught Exception in: 50=validateLogins|org.appwork.utils.net.HeaderCollection.add(Lorg/appwork/utils/net/HTTPHeader;)Lorg/appwork/utils/net/HTTPHeader; --ID:50TS:1672678089578-1/2/23 11:48:09 AM - [] -> Exception thrown at jd.SecondLevelLaunch$4.uncaughtException(SecondLevelLaunch.java:526): java.lang.NoSuchMethodError: org.appwork.utils.net.HeaderCollection.add(Lorg/appwork/utils/net/HTTPHeader;)Lorg/appwork/utils/net/HTTPHeader; at jd.http.RequestHeader.put(RequestHeader.java:96) at jd.http.RequestHeader.put(RequestHeader.java:100) at jd.http.Request.getDefaultRequestHeader(Request.java:457) at jd.http.Request.<init>(Request.java:282) at jd.http.requests.PostRequest.<init>(PostRequest.java:79) at jd.http.Browser.createPostRequest(Browser.java:874) at jd.http.Browser.createPostRequest(Browser.java:859) at org.jdownloader.api.myjdownloader.api.MyJDownloaderAPI.post(MyJDownloaderAPI.java:84) at org.jdownloader.myjdownloader.client.AbstractMyJDClient.cryptedPost(AbstractMyJDClient.java:416) at org.jdownloader.myjdownloader.client.AbstractMyJDClient.connect(AbstractMyJDClient.java:376) at org.jdownloader.api.myjdownloader.MyJDownloaderController$3.run(MyJDownloaderController.java:332) Code:
--ID:50TS:1672678089574-1/2/23 11:48:09 AM - [jd.http.Browser(setProxySelector)] -> Use local proxy: org.jdownloader.api.myjdownloader.api.MyJDownloaderAPI$MyJDownloaderAPIBrowser$1@5e46dc8a wished: org.jdownloader.api.myjdownloader.api.MyJDownloaderAPI$MyJDownloaderAPIBrowser$1@5e46dc8a |
#3
|
|||
|
|||
Nevermind. That stack trace led me to this post: https://board.jdownloader.org/showthread.php?p=514192
Apparently I had a version mismatch with JDownloader.jar and had to wipe my tmp and update directories and delete the Core.jar file. Although the real problem is that http://installer.jdownloader.org/JDownloader.jar doesn't return the latest, most up-to-date version of JDownloader.jar. According to that post it's some outdated stub that later updates itself to the newest version. So if you had a newer version and then it got deleted and redownloaded you get the version mismatch and everything breaks. It's crazy to me (as a developer) that you're shipping two different incompatible versions of this file. It shouldn't even be extra work to update the "installer" version - there should just be one url that everything is pointing at. Why wouldn't your updater look for the newest version at the normal installation url? If for some reason they have to be separate files, why wouldn't the installer stub have a different name? |
#4
|
||||
|
||||
I'm sorry we were not present during christmas/new year.
Another developer will reply in this request once he finds the time.
__________________
JD Supporter, Plugin Dev. & Community Manager
Erste Schritte & Tutorials || JDownloader 2 Setup Download |
Thread Tools | |
Display Modes | |
|
|