Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reCAPTCHA causing null input error #118

Open
Kyrielight opened this issue Dec 6, 2017 · 60 comments
Open

reCAPTCHA causing null input error #118

Kyrielight opened this issue Dec 6, 2017 · 60 comments

Comments

@Kyrielight
Copy link

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
Copy link
Owner

sm00th commented Dec 6, 2017

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
Copy link
Author

Kyrielight commented Dec 6, 2017

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
Copy link
Owner

sm00th commented Dec 6, 2017

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
Copy link
Author

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
Copy link
Owner

sm00th commented Dec 6, 2017

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
Copy link

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
Copy link

penny64 commented Dec 6, 2017

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

@sm00th
Copy link
Owner

sm00th commented Dec 7, 2017

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
Copy link
Author

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

@sm00th
Copy link
Owner

sm00th commented Dec 7, 2017

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.

@sm00th sm00th reopened this Dec 7, 2017
@mjj29
Copy link

mjj29 commented Dec 13, 2017

How do I get a token?

@sm00th
Copy link
Owner

sm00th commented Dec 13, 2017

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
Copy link
Author

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
Copy link
Owner

sm00th commented Dec 13, 2017

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
Copy link

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

@blindndangerous
Copy link

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

@PineapplePet
Copy link

Agree. Super thankful!

@BlazerHeat
Copy link

there is no token Key in my storage

@sm00th
Copy link
Owner

sm00th commented Aug 1, 2018

you need to login for it to be stored there

@zertap
Copy link

zertap commented Aug 15, 2018

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
Copy link
Owner

sm00th commented Aug 15, 2018

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

@stevesbrain
Copy link

stevesbrain commented Sep 19, 2018

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
Copy link

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
Copy link

Chemrat commented Feb 26, 2019

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
Copy link

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
Copy link
Owner

sm00th commented Feb 26, 2019

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.

@sm00th sm00th mentioned this issue Apr 29, 2019
@dequis
Copy link
Contributor

dequis commented May 12, 2019

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
Copy link
Contributor

Alcaro commented May 12, 2019

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
Copy link

fuzzy76 commented Mar 30, 2020

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
Copy link
Owner

sm00th commented Mar 30, 2020

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
Copy link

fuzzy76 commented Mar 30, 2020

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
Copy link
Owner

sm00th commented Mar 30, 2020

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
Copy link

fuzzy76 commented Mar 30, 2020

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
Copy link
Contributor

Alcaro commented Mar 30, 2020

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
Copy link
Contributor

dgw commented Mar 30, 2020

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
Copy link
Owner

sm00th commented Mar 30, 2020

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
Copy link

fuzzy76 commented Mar 30, 2020

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
Copy link
Contributor

dgw commented Mar 30, 2020

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
Copy link

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
Copy link
Owner

sm00th commented Mar 31, 2020

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.

mbologna pushed a commit to mbologna/docker-bitlbee that referenced this issue Apr 1, 2020
@fuzzy76
Copy link

fuzzy76 commented Apr 13, 2020

Can confirm it works now :)

@chrisleaman
Copy link

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
Copy link
Owner

sm00th commented May 14, 2021

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
Copy link

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

@digitalcircuit
Copy link
Contributor

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
Copy link
Owner

sm00th commented Sep 8, 2021

@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
Copy link
Contributor

@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
Copy link

Thaodan commented Sep 22, 2021

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
Copy link

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
Copy link

Wibjarm commented Sep 27, 2021

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
Copy link

Thaodan commented Sep 28, 2021

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

@Sophira
Copy link

Sophira commented Jan 24, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests