32P login issues via Mylar

Post any problems / bugs / issues that are Mylar-related in here.
Post Reply
CraftyClown
Posts: 119
Joined: Fri Jan 30, 2015 9:49 pm

32P login issues via Mylar

Post by CraftyClown » Sun Jun 10, 2018 1:36 pm

Hello mate,

I'm getting error messages in the log about 32P failed logins and a screengrab that says my IP has been banned if I do any searches, however my login at 32P seems to be working fine. In addition if I go to the search providers tab and test the connection I am getting a green tick.

Code: Select all

2018-06-10 14:34:20	ERROR	Uncaught exception: Traceback (most recent call last):
File "C:\Mylar\mylar\logger.py", line 336, in new_run
old_run(*args, **kwargs)
File "C:\Python27\lib\threading.py", line 754, in run
self.__target(*self.__args, **self.__kwargs)
File "C:\Mylar\mylar\webserve.py", line 1439, in queueissue
foundcom, prov = search.search_init(ComicName, ComicIssue, ComicYear, SeriesYear, Publisher, issues['IssueDate'], storedate, IssueID, AlternateSearch, UseAFuzzy, ComicVersion, mode=mode, ComicID=ComicID, manualsearch=manualsearch, filesafe=ComicName_Filesafe, allow_packs=AllowPacks, torrentid_32p=TorrentID_32p)
File "C:\Mylar\mylar\search.py", line 334, in search_init
findit = NZB_SEARCH(ComicName, IssueNumber, ComicYear, SeriesYear, Publisher, IssueDate, StoreDate, searchprov, send_prov_count, IssDateFix, IssueID, UseFuzzy, newznab_host, ComicVersion=ComicVersion, SARC=SARC, IssueArcID=IssueArcID, RSS="no", ComicID=ComicID, issuetitle=issuetitle, unaltered_ComicName=unaltered_ComicName, allow_packs=allow_packs, oneoff=oneoff, cmloopit=cmloopit, manual=manual, torznab_host=torznab_host, torrentid_32p=torrentid_32p)
File "C:\Mylar\mylar\search.py", line 607, in NZB_SEARCH
a = auth32p.info32p(searchterm=searchterm)
TypeError: __init__() should return None, not 'str'
2018-06-10 14:34:20	ERROR	[32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
2018-06-10 14:34:20	WARNING	[32P-AUTHENTICATION] Both session key and credential-based logins failed.
2018-06-10 14:34:20	ERROR	[32P-AUTHENTICATION] The data returned by the login page was not JSON: 
Any idea what the problem might be?

CraftyClown
Posts: 119
Joined: Fri Jan 30, 2015 9:49 pm

Re: 32P login issues via Mylar

Post by CraftyClown » Sun Jun 10, 2018 1:42 pm

So upon further testing the issue only appears to be with authentication mode. If I switch to legacy mode I'm not getting any problems. Is there a downside to using legacy over authentication mode?

User avatar
evilhero
Site Admin
Posts: 2274
Joined: Sat Apr 20, 2013 3:43 pm
Contact:

Re: 32P login issues via Mylar

Post by evilhero » Sun Jun 10, 2018 2:13 pm

Downside is that you can't do backlog search and have to rely solely on what's on the RSS feeds (and the cache it generates over time).

Did you change your password recently on 32p? Make sure it's correct (check in the config.ini - if it's within double quotation marks there's a leading /trailing space that shouldn't be there).

I would try to delete the cache/32p_cookies.dat file as that holds your credentials (make sure mylar isn't running first).

Then start it up and try the search again.

It's disabling it within mylar so you don't hit your logon limit with 32p and get a temporary ban for your troubles.

Arathen
Posts: 34
Joined: Wed Dec 10, 2014 11:30 pm

Re: 32P login issues via Mylar

Post by Arathen » Thu Jun 28, 2018 1:09 am

I have exactly the same problem. Not sure when it started happening, but I successfully grabbed stuff from 32p on 20/6/2018.

I've tried deleting the cache/32p_cookies.dat file but that doesnt seem to help. Clicking "Test connection" yields a green tick and Success message, but also says my inkdrops are NaN.

Log says:

28-Jun-2018 10:15:34 - ERROR :: mylar.valid_login_attempt.538 : CP Server Thread-7 : [32P-AUTHENTICATION] The data returned by the login page was not JSON

followed by a bunch of HTML, which includes:

<h2>Error</h2>
<p class="pagedetails">
Your IP has been banned. </p>

Again, I can log into the site via a browser successfully.

This may not be an actual Mylar problem. It could be a change to the way 32p/CF works.

Worth mentioning is the fact that I also have a VPN. I understand the 32p rules regarding this, and while I do use Auth mode, I also manually route the two IP's for 32p outside the VPN so they go down a normal connection. Has anything changed within Mylar which would make a connection using a DNS name or IP address other than the defaults?

EDIT: I sent a Staff PM on 32p asking for more information and was told that my account has been banned due to
Mylar. Too many failed login attempts, dozens upon dozens upon dozens of them.
Something has clearly gone wrong somewhere here. My user credentials haven't changed, nor have I regenerated a passkey any time recently. My browser access from a different PC was still working, but I don't know why my logins from Mylar would have suddenly started to fail. Any ideas?

Also, as a feature request, can it be made more obvious when logins are failing please? I know I could pro-actively trawl through the logs every day just in case, but something like a big flashing red light would be most appreciated if possible. As I said above, even clicking "Test connection" returns a false positive which leads the user to believe everything is ok when it isn't.

Thanks.

User avatar
evilhero
Site Admin
Posts: 2274
Joined: Sat Apr 20, 2013 3:43 pm
Contact:

Re: 32P login issues via Mylar

Post by evilhero » Thu Jun 28, 2018 4:38 pm

Not entirely sure what's going on - adding a VPN into the mix, probably isn't helping things obviously (as I and others I talk to daily use 32p with no VPN and have never had a problem thus far), but that's neither here nor there and doubtful if that's the root cause of the logon failures.

One thing to check though - When you messaged the staff did you happen to inquire if it was your home IP attempting to logon or was it via your VPN ip ? If you can logon from your browser, but not Mylar and they're both using the same IP (ie. non-VPN), if you sign-off of 32p in your browser and go back to the sign-on page it should say either 'banned' or 'X attempts left' kinda thing. If it doesn't say that, then the IP that Mylar is using is not the same as the one the browser is using.

Usually what happens is Mylar keeps the 32p_cookies.dat file as a session file with your credentials. When it goes to signon, it will use the .dat file to see if that works and if it does no worries. The problem becomes when the cookies.dat file fails or expires (I think it's like 6-9 months, but can't remember exactly) - when either happens it tries to logon and fails. At this point, it then tries to do a normal logon. If the captcha is up at this particular time, it will fail everytime until the captcha is removed by 32p (usually it's just a time-related problem cause they're getting hammered). Once it fails once, it will disable 32p as a provider and then it's a manual process to re-enable. This of course happens on every search, so the 'dozens and dozens' is probably just Mylar going thru it's normal search regiment - it should have disabled 32P though previously (unless however you manually re-enabled it).

Since you deleted the 32p_cookies.dat file already, make sure you shutdown Mylar. Go to your config.ini and check your username / password for 32p therein (if either are enclosed in quoation marks, there's a leading/trailing space in it which is the problem).

There should also be some log lines leading up to the log line you listed - namely the status code being returned from 32p as well as any/all exceptions encountered. Can you check to see what/if either was present and provide them ?

The 32p logon code was actually provided by one of the dev's of 32p as a way of helping out users signing into 32p using Mylar. He provided the base, and I just changed enough to allow it to be integrated into Mylar. So not quite sure if it's a problem with the code itself at this point (at least that aspect of it).

As far as the notification about failure - yeah it should be something different. What it does now is that it will return successful if it can reach 32p, but the NaN for inkdrops would mean that it's failing to authenticate. I'll have to look into it some more and see what's happening and try to get a proper response/action in Mylar to display. The error/status codes being returned helps in seeing what Mylar can determine.

Arathen
Posts: 34
Joined: Wed Dec 10, 2014 11:30 pm

Re: 32P login issues via Mylar

Post by Arathen » Fri Jun 29, 2018 3:59 am

I've ruled out the VPN. That seems to be working correctly, and i've confirmed on the site that all my sessions are coming from my ISP IP address - I can see my browser session and the various Mylar sessions (whats up with the random rotating user agent string?). And yes, you're correct. Had I logged out of the site in my browser, I would not have been able to get back in.

I checked my username and password. They both appeared to be correct (and like I said, they haven't changed in many months), but I also re-entered them anyway because hey, thats what you do right? Once I was unbanned, clicking "Test connection" worked, created a new .32p_cookies.dat file with valid looking content, retrieved my inkdrops, grabbed a torrent successfully, and all looked good each time I checked over the next few hours. That was yesterday.

This morning there were a couple of new commits to apply, so I updated. After Mylar restarted, this is what I found in the log:

Code: Select all

29-Jun-2018 10:50:49 - INFO    :: mylar.shutdown.1178 : MAIN : Mylar is updating...
29-Jun-2018 10:50:53 - INFO    :: mylar.shutdown.1189 : MAIN : Mylar is restarting...
29-Jun-2018 10:50:53 - INFO    :: mylar.shutdown.1197 : MAIN : Restarting Mylar with ['/usr/bin/python', '/home/mylar/mylar/Mylar.py', '-q', '-d', '--nolaunch']
29-Jun-2018 11:01:01 - WARNING :: mylar.Process.384 : Thread-13 : There were no files located - check the debugging logs if you think this is in error.
29-Jun-2018 11:04:26 - ERROR   :: mylar.valid_skey_attempt.463 : Thread-13 : Got an exception [HTTPSConnectionPool(host='32p.obfuscated', port=443): Read timed out. (read timeout=60)] trying to GET to: https://32p.obfuscated/ajax.php
29-Jun-2018 11:05:16 - ERROR   :: mylar.valid_login_attempt.538 : Thread-13 : [32P-AUTHENTICATION] The data returned by the login page was not JSON: <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
    
SNIP to remove 32p login page HTML

    </head>
    <body>
    
SNIP again

    <form id="loginform" method="post" action="login.php" onsubmit="event.preventDefault();formVal();attempt_login();">
                <div id="formdiv">
        <div id="innerform">
        <span id="formnotice" class="notice hidden">
            You have <span class="info">6</span> attempts remaining.<br /><br />
            <strong>WARNING:</strong> You will be banned for 6 hours after your login attempts run out!
        </span>
        <div id="formerror" id="responsePost" class="warning hidden">
                        <br /><br />
        </div>
        <div style="margin:5px 8px; padding: 5px 0 0 0; height: 22px;">
            <input placeholder="Username" type="text" name="username" id="username" required="required" maxlength="20" pattern="[A-Za-z0-9_?]{1,20}" autofocus="autofocus" />
        </div>
        <div style="margin:5px 8px; padding: 0 0 5px 0; height: 22px;">
            <input placeholder="Password" type="password" name="password" id="password" required="required" maxlength="100" pattern=".{6,100}" />
        </div>
        <div id="twostep_tr" style="margin:5px 8px; height: 22px;" class="hidden">
           <input placeholder="Two-Factor Authentication" type="text" name="twostep_pub" id="twostep_pub"/>
        </div>

        <span style="text-align: left; padding: 12px 10px 12px; display: block;border-radius: 0 0 5px 5px;">
            <span>
                <input type="checkbox" id="keeplogged" name="keeplogged" value="1" />
                <label for="keeplogged">Remember me</label>
                <input type="submit" name="login" value="Login" class="submit" id="loginButton"></input>
            </span>
        </span>
      </div>
      </div>
    </form>
<br />
<br />
Lost your password? <a href="login.php?act=recover">Recover it here!</a>

SNIP again


29-Jun-2018 11:05:16 - WARNING :: mylar.login.624 : Thread-13 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
29-Jun-2018 11:05:16 - ERROR   :: mylar.__init__.41 : Thread-13 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
Thats obviously the default login page. I checked my .32p_cookies.dat file and it hasn't changed and still contains the data from yesterday, so I dont know why it would be failing to login again. Sorry theres no debug messages - obviously a daemon restart after an update turns debugging off? I know you asked for a status code, but my guess is its a 200 because a login page is still a successful return.

Ive obviously disabled 32p as a provider until an answer for this can be found. Ive already had a ban and a warning from them and I dont particularly want to lose my 32p account permanently.

Thanks.

User avatar
evilhero
Site Admin
Posts: 2274
Joined: Sat Apr 20, 2013 3:43 pm
Contact:

Re: 32P login issues via Mylar

Post by evilhero » Fri Jun 29, 2018 3:21 pm

Well the updates that went up a few days ago had nothing to do with 32p or authenticating in anyway (if you had thought that one of the updates did something to that codebase).

The line that catches me:

Code: Select all

Got an exception [HTTPSConnectionPool(host='32p.obfuscated', port=443): Read timed out. 
Now, I'm not sure if you replaced the host with the word 'obfuscated' or if that was present (if it was present, then I would think that's not normal, but I've never seen that message either tbh). But regardless, the 'read timeout' is the important part - either 32P is taking a long time to respond to the logon request, or the connection to 32P is slow, or possibly even a combo of both.

Do you have 2FA enabled for 32P ?

As for the restart, Mylar will restart with the options provided during startup. If you used the -v switch to start, then it should retain it across restarts. If however you just enabled it via the Logs tab, then yes it will not be persistent across reboots (and this is on purpose in this regards).

It's unfortunate that these things are happening to users, but for the vast majority the problems usually stem from a user problem of some kind and not Mylar (not saying that Mylar's not at fault - the repeated attempts when it should be disabled is not good). Like I mentioned above, I along with lots of other use 32P with auth mode and haven't had any problems (except for me when I purposely tried to get locked out - heh). I know of others though, that have experienced temp bans to full bans when using Mylar, but again - it's different for every user and it's questionable if Mylar is to blame for the aspect of the ban in those cases (ie. multiple ip's, vpn's, changed passwords, etc).

I'll have to reach out to 32P staff and see if they might be able to offer some kind of help with this stuff in regards to letting me see some of the errors/problems from their vantage point. My goal with Mylar is not to make things tougher for users, but the exact opposite.

Arathen
Posts: 34
Joined: Wed Dec 10, 2014 11:30 pm

Re: 32P login issues via Mylar

Post by Arathen » Sat Jun 30, 2018 12:16 pm

Yes, I obfuscated the URLs on purpose. I seem to remember that being one of the site rules. You don't talk about Fight Club.

I don't have 2FA enabled. Im not sure why that particular connection attempt timed out, but i'll keep a lookout for more in case its a dodgy connectivity problem with my link.

I've updated again today due to the latest commit that you provided. I went in after updating and hit "Test connection" again because i'm paranoid now, and everything seems to still be working ok. So, yeah, I don't know what happened.

I think the thing that causes me the most angst (behind potentially losing my login) is that it didnt warn me when something went wrong. I didnt change anything other than the usual semi-regular updates/restarts, and I get that things glitch occasionally and no software is perfect - thats understandable and perfectly reasonable, but it would be great if the software provided a early warning.

Anyways, I know you've already mentioned looking at that, so all good. Im certainly not going to ditch Mylar because its been an awesome piece of software for me for a very long time now. Thank you for all the hard work you put into it :)

Cheers.

Arathen
Posts: 34
Joined: Wed Dec 10, 2014 11:30 pm

Re: 32P login issues via Mylar

Post by Arathen » Mon Sep 24, 2018 8:15 am

Sorry to resurrect an old thread, but this has now happened to me yet again, and my 32p account has been banned as a result.
These are the (obfuscated) logs I managed to capture:

Code: Select all

21-Sep-2018 11:02:11 - ERROR   :: mylar.valid_skey_attempt.463 : SEARCH-QUEUE : Got an exception [('Connection aborted.', BadStatusLine("''",))] trying to GET to: https://32p.obfuscated/ajax.php
21-Sep-2018 11:02:17 - ERROR   :: mylar.valid_login_attempt.538 : SEARCH-QUEUE : [32P-AUTHENTICATION] The data returned by the login page was not JSON: <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>News :: 32Pxxxs</title>
    <meta charset='utf-8' />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta name="referrer" content="origin-when-cross-origin" />
    <meta content="32Pxxxs, The Website Where Comics are #1!" name="description" />
<snip, but the complete HTML for the main page follows, which suggests the login did work correctly>
21-Sep-2018 11:02:17 - WARNING :: mylar.login.624 : SEARCH-QUEUE : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 11:02:17 - ERROR   :: mylar.__init__.41 : SEARCH-QUEUE : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 11:07:07 - WARNING :: mylar.Process.384 : Thread-21 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 12:07:07 - WARNING :: mylar.Process.384 : Thread-29 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 13:07:08 - WARNING :: mylar.Process.384 : Thread-26 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 14:07:08 - WARNING :: mylar.Process.384 : Thread-19 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 15:07:08 - WARNING :: mylar.Process.384 : Thread-24 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 16:07:08 - WARNING :: mylar.Process.384 : Thread-15 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 17:07:08 - WARNING :: mylar.Process.384 : Thread-23 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 18:07:08 - WARNING :: mylar.Process.384 : Thread-22 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 19:07:08 - WARNING :: mylar.Process.384 : Thread-21 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 19:26:40 - ERROR   :: mylar.valid_login_attempt.545 : Thread-13 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 1, u'twostep': u'false'}
21-Sep-2018 19:26:40 - WARNING :: mylar.login.624 : Thread-13 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 19:26:40 - ERROR   :: mylar.__init__.41 : Thread-13 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 19:46:41 - ERROR   :: mylar.valid_login_attempt.545 : Thread-14 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 2, u'twostep': u'false'}
21-Sep-2018 19:46:41 - WARNING :: mylar.login.624 : Thread-14 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 19:46:41 - ERROR   :: mylar.__init__.41 : Thread-14 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 19:54:51 - WARNING :: mylar.Process.384 : Thread-13 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 20:06:41 - ERROR   :: mylar.valid_login_attempt.545 : Thread-15 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 2, u'twostep': u'false'}
21-Sep-2018 20:06:41 - WARNING :: mylar.login.624 : Thread-15 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 20:06:41 - ERROR   :: mylar.__init__.41 : Thread-15 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 20:26:40 - ERROR   :: mylar.valid_login_attempt.545 : Thread-16 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 3, u'twostep': u'false'}
21-Sep-2018 20:26:40 - WARNING :: mylar.login.624 : Thread-16 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 20:26:40 - ERROR   :: mylar.__init__.41 : Thread-16 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 20:46:40 - ERROR   :: mylar.valid_login_attempt.545 : Thread-13 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 4, u'twostep': u'false'}
21-Sep-2018 20:46:40 - WARNING :: mylar.login.624 : Thread-13 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 20:46:40 - ERROR   :: mylar.__init__.41 : Thread-13 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 20:54:51 - WARNING :: mylar.Process.384 : Thread-17 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 21:06:40 - ERROR   :: mylar.valid_login_attempt.545 : Thread-22 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 4, u'twostep': u'false'}
21-Sep-2018 21:06:40 - WARNING :: mylar.login.624 : Thread-22 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 21:06:40 - ERROR   :: mylar.__init__.41 : Thread-22 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 21:26:40 - ERROR   :: mylar.valid_login_attempt.545 : Thread-14 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 5, u'twostep': u'false'}
21-Sep-2018 21:26:40 - WARNING :: mylar.login.624 : Thread-14 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 21:26:40 - ERROR   :: mylar.__init__.41 : Thread-14 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 21:46:40 - ERROR   :: mylar.valid_login_attempt.545 : Thread-19 : [32P-AUTHENTICATION] Got unexpected status result: {u'status': u'error', u'show_attempts': u'true', u'message': u'You must complete the captcha.', u'attempts': 6, u'twostep': u'false'}
21-Sep-2018 21:46:40 - WARNING :: mylar.login.624 : Thread-19 : [32P-AUTHENTICATION] Both session key and credential-based logins failed.
21-Sep-2018 21:46:40 - ERROR   :: mylar.__init__.41 : Thread-19 : [32P-AUTHENTICATION] [LOGIN FAILED] Disabling 32P provider until login error(s) can be fixed in order to avoid temporary bans.
21-Sep-2018 21:54:51 - WARNING :: mylar.Process.384 : Thread-16 : There were no files located - check the debugging logs if you think this is in error.
21-Sep-2018 22:06:40 - ERROR   :: mylar.valid_login_attempt.538 : Thread-20 : [32P-AUTHENTICATION] The data returned by the login page was not JSON: <!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
    <head>
        <title>Error :: 32Pxxxs</title>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <meta content="32Pxxxs, The Website Where Comics are #1!" name="description" />
<snip>
    <p class="pagedetails">
        Your IP has been banned.    </p>
    </div>
</div>
As you can see, there was an initial failure that doesnt look like a failure, because the login worked well enough to output the entire HTML of the main index page. I know it says "Connection aborted", but thats obviously not true because the whole 32p web page came back. I guess the HTML failed to parse or something.

Then, despite the provider being automatically disabled to prevent bans, after several hours it just started trying again on its own, which eventually led to my IP being banned.

Once again, there was no warning of a problem in the GUI, and no way short of real-time log monitoring to see that it was failing. I guess manually re-testing the connection would have thrown an error, but it isnt really practical to do that every hour of the day.

I dont know if i'll get my 32p account reinstated, because this is now the second time that this has happened and I dont know how many chances they give. Its hard to have trust in the tool when this kind of thing keeps happening tho :(

User avatar
evilhero
Site Admin
Posts: 2274
Joined: Sat Apr 20, 2013 3:43 pm
Contact:

Re: 32P login issues via Mylar

Post by evilhero » Wed Oct 10, 2018 2:57 pm

First and foremost, my sincere apologies for the response delay and more importantly the fact that using Mylar possibly did something to disable your account.

Now onto figuring out the why...

It looks like the RSS was firing off 20 minutes pulling down the RSS feeds, but it was still trying to authenticate in order to pull down the given feeds.

It fails at 11:02, disables then it starts trying again at 19:26 - initially I thought it would occur at the 6-hour mark as that's when the background search fires off (every 6 hours unless it was changed), but that's 8 hours difference.

Now if I recall correctly, when it can't signon properly it deletes the existing 32p_cookies.dat file so that it can properly recreate it (in case it's a stale entry), then tries to authenticate in order to successfully signon. According to the logs thereafter, that the captcha was up on 32P at the time it was attempting to signon (u'message': u'You must complete the captcha'), which would result in a failed logon attempt as Mylar cannot signon with the captcha present. Thus the importance of the .dat file and keeping it up to date, as it will allow you to signon with the captcha present. Because you're only logging errors/warnings, it makes it difficult to see if anything else was happening beneath the surface that was stopping things/or why/how it got re-enabled.

The kicker here is the intial error - the bad status line. This usually happens when the remote server/proxy terminates a HTTPS connection. It can't send back headers, because it can't read the encrypted data going back and forth, so it sends back the empty string. The requests library (because it's built on httplib) fails with the above message. The thing being if it fails with the termination, we should pause for a few seconds (roughly), and then try a single retry - disabling it sure works, but it might just be that it was receiving too many requests in order to process the later query and it fails.

Now of course this is neither here nor there at this point in time - it should be disabling it permanently after the initial failure and it would become a manual re-enabling so that the user can verify everything works. This is what I had understood was occurring based on some previous interactions with others & myself using the program. I did find a slight discrepancy in some of the code for this, albeit I don't think it would affect what was occurring here.

Post Reply