reCAPTCHA causing null input error

[Kyrielight]

I kept getting the null error when attempting to log into Discord, and a quick debug output shows that login is failing because the reCAPTCHA code section is blank and required (thus returning a 400).

Not exactly sure how this could be bypassed given Discord doesn't like botting into user accounts; I suppose theoretically one could MAC spoof to authenticate beforehand?

[sm00th]

aw snap, they've added captcha now? do you have debug output for this? (remember to remove any passwords/tokens before posting it)
I am not getting these atm, but I guess thats because I connect from an ip that is already known

[Kyrielight]

Yep! Here's some output:

HTTP response headers:
HTTP/1.1 400 BAD REQUEST
Date: Wed, 06 Dec 2017 12:14:20 GMT
Content-Type: application/json
Content-Length: 37
Connection: keep-alive
Set-Cookie: __cfduid=(not sure if this is important so I removed it); expires=Thu, 06-Dec-18 12:14:20 GMT; path=/; domain=.discordapp.com; HttpOnly
Strict-Transport-Security: max-age=31536000; includeSubDomains
Via: 1.1 google
Alt-Svc: clear
Server: cloudflare-nginx
CF-RAY: 3c8f2a128e8e6c3a-SJC

Finishing HTTP request with status: 400 BAD REQUEST
[04:14:20] <<< ((null)) discord_http_login_cb [400] 37
{"captcha_key": ["captcha-required"]}

I also tried logging out of Discord and logging back in on several of my devices; they all required me to do captcha sign-in. I also tried to use my server as a SOCK5 proxy + Firefox and logged in successfully, but still received the captcha error, so I'm guessing I would have to spoof to appear to be the application itself.

[sm00th]

So it doesn't work even after a succesfull login from a browser?
I wonder why. I thought mine worked because I already had an auth token, but after resetting it biltbee-discord managed to get a new one without an issue.

[Kyrielight]

I'm not quite following you, forgive me; how are you using an auth-token to sign into your account? (I'm just using my email/password since I thought auths are only for bots)

[sm00th]

Discord requires an auth token for every request bitlbee-discord does, so it actually caches the auth token and uses that till it gets invalidated and only after that it sends the credentials to get a new one.
My idea was that discord applies captcha to login page only.

[rodneyrod]

It could be set on a per-account basis, maybe too many incorrect logins?

Or worse, it could be the testing phase of a wider rollout.

[penny64]

Probably should add support for logging in with a token now, it's not hard to get

[sm00th]

Probably should add support for logging in with a token now, it's not hard to get

The option is there, it is just hidden
acc off discord
acc discord set token_cache xxxxxxxx

[Kyrielight]

Can confirm directly setting the token allows me to log in from any previously unauthorized device. Thanks a bunch guys!

[sm00th]

Let's leave it open since we still have to deal with the capcha somehow. Also people would be able to find the workaround here until the issue is really solved.

[mjj29]

How do I get a token?

[sm00th]

How do I get a token?

You can login with your browser with "Web Developer"(in firefox)/"Developer Tools"(in chrome) in "network" mode. You should see a POST request to "login" with a response like {"token": "xxxxxxx"}

[Kyrielight]

Chrome's token can also be accessed under Developer Tools --> Application, where under the local storage dropdown, select https://discordapp.com and one of the Key/Value pairs is token/(your token).

[sm00th]

Neat, apparently FF has something similar: Web Developer -> Storage Inspector -> Local Storage -> http://discordapp.com -> token

This is way easier than monitoring "network", thanks.

[stevesbrain]

Thanks for the hint - setting token cache works for me too now :)

[blindndangerous]

Thanks for keeping this open. Would've never figured out what to do without this issue.

[PineapplePet]

Agree. Super thankful!

[BlazerHeat]

there is no token Key in my storage

[sm00th]

you need to login for it to be stored there

[zertap]

At least on firefox, the token only appears for a few moments until discord loads completely. So I had to ctrl+f5 and copy it really quickly before it disappears.

[sm00th]

Looks like discord changed this behavior and it would probably be easier to use the method from my earlier comment #118 (comment)

[stevesbrain]

For other folks looking, if you've got MFA on, it's on the response to the POST to https://discordapp.com/api/v6/auth/mfa/totp (rather than to login) :)

[slackhead]

What is "MFA on"?

I see in that link a method not allowed error. Not sure what/how to affect that in bitlbee.

I've looked at my qutebrowser (chromium based) local storage with sqlite3 and it shows token as X'......' I wasn't sure whether to include the X'' in the token setting, but neither seems to work anyway.

I'm logged in right now in my browser (after having to do a shedload of captchas, and responding to emails), but bitlbee is failing to login. If it matters, I need to use a proxy to connect out and I've set it in the /etc/bitlbee/ conf file. I don't have any other accounts in bitlbee so I can't tell if it's a proxy issue or not.

How can I debug the connection attempts? All I'm seeing is login error. Failed to get info about self.

[Chemrat]

MFA/2FA is multi- or two-step factor authentication, means each client has to be authorized by other means (usually one-time password generated by some other device). It's on your account settings page.

I'm not a developer, but if you have to deal with captchas, bitlbee might not be able to make it past them.

[slackhead]

Ah right. I didn't set up two-factor because I assumed it might involve giving them my mobile number, and nobody gets that apart from some important sites like my bank.

[sm00th]

Hi @slackhead, please see the "Debugging" section at the bottom of README. This will help you get exact requests and responses bitlbee and discord are exchanging.

[dequis]

Another way to get a token with firefox and some commands, first quit firefox and do:

cd ~/.mozilla/firefox/*.default
sqlite3 webappsstore.sqlite
select value from webappsstore2 where originKey = 'moc.ppadrocsid.:https:443' and key = 'token';

You can probably skip the "quit firefox" step if you copy "webappsstore.sqlite" to a different location but when I did that the token wasn't there.

For most people, going to dev tools/storage pane is probably still the easiest way, but the token is very hard to reach with keyboard navigation and screen readers.

(we should maybe have proper documentation and proper error messages for this?)

[Alcaro]

Alternatively, you can skip the 'quit firefox' step if you replace sqlite3 webappsstore.sqlite with sqlite3 file:webappsstore.sqlite?immutable=1, and ensure the database doesn't change while you're running your query.

To do the latter part, type quickly. Or type the query in advance: echo "select value from webappsstore2 where originKey = 'moc.ppadrocsid.:https:443' and key = 'token'" | sqlite3 file:webappsstore.sqlite?immutable=1

[fuzzy76]

Is this still supposed to work? I found my token, but when I issue account discord on absolutely nothing happens. No error message or anything. I then try chat list discord and it says "Not logged in to account".

[sm00th]

Yes, this still works.

absolutely nothing happens

That doesn't sound right, you should at least see some <@root> discord - Logging in messages. If you don't see these then bitlbee probably didn't get your acc on command.

If you see "logging in" messages but it never succesfully logins you can try following Debugging section from README to gather more info.

[fuzzy76]

18:44 <@Fuzzy76> account discord on
18:44 <@Fuzzy76> acc discord on
18:44 <@root> Account already online
18:44 <@Fuzzy76> chat list discord
18:44 <@root> Not logged in to account.
18:44 <@Fuzzy76> account discord off
18:44 <@root> discord - Logging in: Signing off..
18:44 <@Fuzzy76> account discord on
18:45 <@Fuzzy76> chat list discord
18:45 <@root> Not logged in to account.
18:45 <@Fuzzy76> account discord off
18:45 <@root> discord - Logging in: Signing off..

[sm00th]

Ok, so I was a bit wrong ant it doesn't report much during login, only if it errors out or successfully logs in. None of the two happens in your log, so it is still in process of logging in or parsing your discord servers.

First of all make sure you are running the latest version of bitlbee-discord because we had issues with login timeouts recently (#201, #202). Then give it a bit more time, you should either see
19:45 <@root> discord - Logging in: Logged in or a time-out error.

[fuzzy76]

I'm using https://github.com/mbologna/docker-bitlbee which in turn uses 0.4.2 which is the latest.

After waiting a bit it goes like this:

21:26 <@Fuzzy76> account discord on
21:28 <@root> discord - Login error: Connection timeout
21:28 <@root> discord - Logging in: Signing off..
21:28 <@root> discord - Logging in: Reconnecting in 45 seconds..
21:31 <@root> discord - Login error: Connection timeout
21:31 <@root> discord - Logging in: Signing off..
21:31 <@root> discord - Logging in: Reconnecting in 135 seconds..

[Alcaro]

0.4.2 is the latest release, but not the latest commit. 042 was released in december 2018; #202 was fixed this month.

May be time to make a new release?

[dgw]

May be time to make a new release?

Probably. 15 months is a long time! (I say, as if I don't manage a project that's gone longer.)

[sm00th]

Agreed. These changes are important enough to warrant a release so that people won't get confused.

I wonder though why @mbologna chose to fetch 0.4.2 specifically instead of just getting latest git HEAD like with other plugins in docker-bitlbee?

[fuzzy76]

Probably because it's your newest release. :) Would've been my go to as well. Fetching head from other peoples' repos will sooner or later break your build. I've learnt that the hard way myself.

[dgw]

Fetching head from other peoples' repos will sooner or later break your build.

A Docker-based GitHub action did that to me a few weeks ago, errors popped up because it was fetching the latest (pre-release) revision instead of the last stable. Always fetch tags!

[mbologna]

I wonder though why @mbologna chose to fetch 0.4.2 specifically instead of just getting latest git HEAD like with other plugins in docker-bitlbee?

When the project offers releases, I tend to prefer them over HEAD. And that is why you can find a mix of these approaches when looking at the plugins I included in docker-bitlbee.

The reason is a simple convention: releases should more stable, as HEAD is usually bleeding edge.

[sm00th]

Fair enough. Although with bitlbee-discord being in maintenance mode and me always forgetting to tag new versions it is more likely that relased version will be the one not working. Not trying to change your mind though, thats a good approach in general.

I've tagged 0.4.3 now with said fixes.

[fuzzy76]

Can confirm it works now :)

[chrisleaman]

Can anyone confirm it is still possible to get the token using the methods listed above? I tried Dev Tools in both Chrome and Firefox, but there doesn't seem to be a token with either method. I have 2FA enabled if that makes any difference...

[sm00th]

Can anyone confirm it is still possible to get the token using the methods listed above? I tried Dev Tools in both Chrome and Firefox, but there doesn't seem to be a token with either method. I have 2FA enabled if that makes any difference...

Hm, it wasn't there when I first looked but showed up after I logged out and logged in again. Worked with MFA as well.

[chrisleaman]

Managed to get the token - used Chrome in ingocnito mode + dev tools to get it from local storage. Thanks for your help!

[digitalcircuit]

For anyone recently getting tokens, I've found out on Firefox at least that the token value may be hidden unless you're in Responsive Design Mode, as pointed out here.

1. Log into Discord
2. Switch to Storage DevTools tab
3. Press Ctrl+Shift+M or click the Responsive Design Mode button near the DevTools close button on the top-right
4. See your token show up in the storage view
5. For added fun, turn off Responsive Design Mode and watch the token be hidden away somewhere

I assume Discord changed the token storage method, perhaps as a way to try to stop people from extracting it. I don't know why it shows up again in mobile view; perhaps it's part of the mobile client login process..? I have no idea.

[sm00th]

@digitalcircuit thanks for the writeup. I'll probably need to move the best comments from this thread to a 'Q&A' section of 'discussions'.

[digitalcircuit]

@sm00th Makes sense! The need to manage tokens looks like it's affecting other clients too, as was pointed out to me on #bitlbee, so there might be opportunity for collaboration.

(…I also wound up making a badly drawn meme/logo as a result of the account password resets, as unexpectedly shown in the issue linked above. So… PNG and SVG, CC-0.)

[Thaodan]

The debugging may be either on or off and if you are seeing the 'failed to switch to websocket mode' you should definitely see the other one in debug log since they are right next to each other in sources. It won't be a http request any more but rather a '<<<(null)' type of message.

I have the same issue in that function. setting token_cache didn't help.

[16:58:56] >>> ((null)) discord_http_get 217
About to send HTTP request:
GET /api/gateway HTTP/1.1
Host: discordapp.com
User-Agent: Bitlbee-Discord
Content-Type: application/json
authorization: 
<you wish you had it>


HTTP response headers:
HTTP/1.1 200 OK
Date: date
Content-Type: application/json
Content-Length: 35
Connection: keep-alive
strict-transport-security: max-age=31536000; includeSubDomains
x-envoy-upstream-service-time: 10
Via: 1.1 google
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
CF-Cache-Status: HIT
Age: 82315
Expires: date
Cache-Control: public, max-age=30
Accept-Ranges: bytes
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=foobar"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY:foobar

Finishing HTTP request with status: 200 OK
[16:58:56] <<< ((null)) discord_http_gateway_cb [200] 35
{"url": "wss://gateway.discord.gg"}

[16:58:57] <<< ((null)) discord_ws_in_cb switching failure. buf:
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Wed, 22 Sep 2021 13:58:57 GMT
Content-Type: text/html
Content-Length: 155
Connection: close
CF-RAY: -

<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>cloudflare</center>
</body>
</html>

[drshapeless]

I have exactly the same error as yours. I obtained my token from firefox and set it in bitlbee. My debug output looks like this.

[22:12:57] >>> ((null)) discord_http_get 188
About to send HTTP request:
GET /api/gateway HTTP/1.1
Host: discordapp.com
User-Agent: Bitlbee-Discord
Content-Type: application/json
authorization: removed


HTTP response headers:
HTTP/1.1 200 OK
Date: Sat, 25 Sep 2021 14:14:07 GMT
Content-Type: application/json
Content-Length: 35
Connection: keep-alive
strict-transport-security: max-age=31536000; includeSubDomains
x-envoy-upstream-service-time: 5
Via: 1.1 google
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
CF-Cache-Status: HIT
Age: 20155
Expires: Sat, 25 Sep 2021 14:14:37 GMT
Cache-Control: public, max-age=30
Accept-Ranges: bytes
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=removed"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY: 6944db6bcc1421e9-HKG

Finishing HTTP request with status: 200 OK
[22:12:57] <<< ((null)) discord_http_gateway_cb [200] 35
{"url": "wss://gateway.discord.gg"}

[22:12:57] <<< ((null)) discord_ws_in_cb switching failure. buf:
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Sat, 25 Sep 2021 14:14:08 GMT
Content-Type: text/html
Content-Length: 155
Connection: close
CF-RAY: -

<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>cloudflare</center>
</body>
</html>

The debugging may be either on or off and if you are seeing the 'failed to switch to websocket mode' you should definitely see the other one in debug log since they are right next to each other in sources. It won't be a http request any more but rather a '<<<(null)' type of message.

I have the same issue in that function. setting token_cache didn't help.

[16:58:56] >>> ((null)) discord_http_get 217
About to send HTTP request:
GET /api/gateway HTTP/1.1
Host: discordapp.com
User-Agent: Bitlbee-Discord
Content-Type: application/json
authorization: 
<you wish you had it>


HTTP response headers:
HTTP/1.1 200 OK
Date: date
Content-Type: application/json
Content-Length: 35
Connection: keep-alive
strict-transport-security: max-age=31536000; includeSubDomains
x-envoy-upstream-service-time: 10
Via: 1.1 google
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
CF-Cache-Status: HIT
Age: 82315
Expires: date
Cache-Control: public, max-age=30
Accept-Ranges: bytes
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=foobar"}],"group":"cf-nel","max_age":604800}
NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
Server: cloudflare
CF-RAY:foobar

Finishing HTTP request with status: 200 OK
[16:58:56] <<< ((null)) discord_http_gateway_cb [200] 35
{"url": "wss://gateway.discord.gg"}

[16:58:57] <<< ((null)) discord_ws_in_cb switching failure. buf:
HTTP/1.1 400 Bad Request
Server: cloudflare
Date: Wed, 22 Sep 2021 13:58:57 GMT
Content-Type: text/html
Content-Length: 155
Connection: close
CF-RAY: -

<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>cloudflare</center>
</body>
</html>

[Wibjarm]

I've been seeing the same "failed to switch to websocket mode" error with the same debug messages, but only since glib2 2.70, if that bit of extra detail helps narrow it down. Downgrading to 2.68 works around it for now.

[Thaodan]

Downgrading works for me I opened #226 about the issue.

[Sophira]

I had the "captcha-required" issue today and can confirm that finding the location at Dev Tools->Application->Local Storage->token works fine and I was able to log in using it (on glib 2.68; I don't know about later glib versions).

For those who are having trouble, here are a couple of tips:

• Make sure you have the right Local Storage key! In addition to the key called token, there's also one called tokens (note the plural), and (at least on my computer) it shows up before the non-plural version.
• Don't copy the quotes around the token - just the parts inside them.

After you log in successfully, I'd recommend logging out again, using account discord set password <your password> to update bitlbee-discord's knowledge of the password, then using account discord set token_cache "" to clear the token cache.