Can't connect: `:error "invalid_auth"`

[ieure]

Describe the bug

I'm not able to connect to Slack.

To Reproduce Steps to reproduce the behavior:

1. Extract the auth token and cookie as described.
2. Eval:

(slack-register-team :name "Work"
                       :disable-block-format t
                       ;; To refresh the token, https://github.com/jackellenberger/emojme#finding-a-slack-token
                       :token (password-store-get "team.slack.com/auth-token")
                       :cookie (password-store-get "team.slack.com/auth-cookie"))
  (slack-start)

3. In *Slack Log - Work, find the following error:

[2022-05-09 10:59:44] [trace] REQUEST FINISHED. URL: "https://slack.com/api/rtm.connect", PARAMS: (("mpim_aware" . "1") ("presence_sub" . "true")), DATA: (:ok :json-false :error "invalid_auth") - Work

Backtrace

No backtrace is generated.

Expected behavior Emacs-Slack should connect to Slack.

Environment:

• OS: Debian Bullseye
• Emacs Version: Built from Git ge6e29b43527, 29.0.50.
• emacs-slack Version: ff46d88

Additional context

I moved to a new Slack workspace due to my work getting acquired. The new workspace worked fine for a couple weeks, then started refusing to connect. The old workspace continues to work fine. Normal auth into the new workspace (in the web client) uses SAML SSO through Okta; I'm not sure if that's relevant, since in the past, once I extract the auth token/s from a logged-in session, I've been able to connect from emacs-slack.

Happy to debug this issue further, but I'm not sure where to start.

[benthamite]

I'm also experiencing this. Workspaces using the old tokens starting with xoxs work fine, but attempts to log in to workspaces using the new tokens starting with xoxc result in the same error reported by @ieure above.

[ieure]

Adding, I saw some other issues mentioning that deleting their .elc files / removing, then reinstalling emacs-slack solved similar issues. Since I was upgrading to a new Emacs snapshot, I went ahead and blew away all my straight.el repos, .elc, and .eln files. Then restarted, got fresh clones and builds. The problem still persists, which makes me think Slack has changed something about their auth mechanism (again) which has broken emacs-slack for xoxc- tokens. And since those seem destined to roll out widely, this will render emacs-slack unusable unless it's fixed.

@aculich, I see you implemented this. Any chance you can take another look to figure out what's wrong?

[ieure]

wee-slack's fix for this: wee-slack/wee-slack#857

I don't currently have time to figure out what they're doing and implement it here, but maybe that'll help someone who does.

[ieure]

Bump. Anyone had a chance to look? Is this actually working for anyone?

[isamert]

wee-slack's fix for this: https://github.com/wee-slack/wee-slack/pull/857 I don't currently have time to figure out what they're doing and implement it here, but maybe that'll help someone who does.

@ieure This fix mentioned here is related to xoxc tokens and it is already fixed in emacs-slack via #552. Please double check the :token and the :cookie parameters you provide (especially be sure that you copy the cookie in the right format, meaning that it should be the encoded version(i.e. it should contain %2F or %3D kind of sequences)) . Better yet, check if the following works with the cookie and token you've gathered:

curl -H 'Cookie: d=xoxd-...' 'https://api.slack.com/api/rtm.connect?token=xoxc-...'

[robert-m-johnson]

I'm also getting authentication errors. I'm trying to authenticate with clojurians.slack.com:

My register command looks like

(slack-register-team
 :name "clojurians"
 :default t
 :token "xoxc-0000000000-0000000000000-0000000000000-0000000000000000000000000000000000000000000000000000000000000000"
 :cookie "xoxd-WoMClAX%2BA<etc>"
 :subscribed-channels '(slackbot))

and the error log I see in the slack log is the same as @ieure reports.

@isamert I was able to get a successful login when using the curl command you described, so I'm sure I've got the correct token & cookie.

[ieure]

@ieure This fix mentioned here is related to xoxc tokens and it is already fixed in emacs-slack via #552. Please double check the :token and the :cookie parameters you provide (especially be sure that you copy the cookie in the right format, meaning that it should be the encoded version(i.e. it should contain %2F or %3D kind of sequences)) . Better yet, check if the following works with the cookie and token you've gathered:

My bug report is that the current fix doesn't work, or doesn't work in all cases. Multiple other people have confirmed they have the same problem.

[isamert]

I'm also getting authentication errors. I'm trying to authenticate with clojurians.slack.com:

My register command looks like

(slack-register-team
 :name "clojurians"
 :default t
 :token "xoxc-0000000000-0000000000000-0000000000000-0000000000000000000000000000000000000000000000000000000000000000"
 :cookie "xoxd-WoMClAX%2BA<etc>"
 :subscribed-channels '(slackbot))

and the error log I see in the slack log is the same as @ieure reports.

@isamert I was able to get a successful login when using the curl command you described, so I'm sure I've got the correct token & cookie.

This is interesting because that curl command is almost same as what emacs-slack is doing, see here1, and the slack-request function adds the cookie and Authorization headers here2. So the real curl command would be:

curl -H 'Authorization: Bearer xoxc-....' -H 'Cookie: d=xoxd-....' 'https://api.slack.com/api/rtm.connect'

I don't think this will make a difference because slack accepts both the Authorization header and the token parameter. slack-emacs also adds some parameters to the request (to test almost exactly same request that slack-emacs is doing. Also note that slack-emacs is literally doing a curl call while doing this as it's using the request.el library unless you've changed it's configuration):

curl -H 'Authorization: Bearer xoxc-....' -H 'Cookie: d=xoxd-....' 'https://api.slack.com/api/rtm.connect?mpim_aware=1&presence_sub=true'

If it's still behaving differently on emacs-slack, it might useful to enable debugging on request.el by setting request-log-level and request-message-level to 'blather or something like that and try to trace where emacs-slack requests differ.

[robert-m-johnson]

Thanks @isamert for that log level advice! Using that, I've done a bit of digging, and the TL;DR is that I think it's related to cookies, but haven't had the time yet to investigate further. If it is indeed related to cookies then this might help explain why this issue isn't seen more widely; perhaps it is only affecting users connecting to a workspace for the first time or something.

What I've found so far is:

• The curl request specifes the d cookie via a header argument (i.e. -H)
• It also specifies the --cookie and --cookie-jar arguments
• The first ever request (after clearing `~/.emacs.d/.cache/request/) sent by emacs-slack succeeds
• Sending manual curl requests with the -v option turned on, I can see that the first response sends back a d-s cookie (presumably for the web socket?).
• Subsequent requests specify the d-s cookie from the cookie jar, as well also the d cookie from the header, and so get sent separately, like so:

> Cookie: d-s=...
> Authorization: Bearer xoxc-...
> Cookie: d=xoxd...

However, if I

1. Manually write my d cookie into the cookie jar file (~/.emacs.d/.cache/request/curl-cookie-jar)
2. Omit the -H argument from my manual curl command

then my manual curl request succeeds!

With this setup, the request log looks like

> Cookie: d-s=...; d=xoxd-...
> Authorization: Bearer xoxc-...
>

So it seems that for some reason Slack isn't receiving the d cookie, and it's somehow related to the d-s cookie being sent up as well via the cookie jar arg. (Sadly, the emacs-slack still fails to connect when the d cookie is manually written in to the cookie jar - I was hoping that could be a workaround.)

I doubt that this is an issue related to curl, but just in case here's my curl version information:

curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

[robert-m-johnson]

With a bit more digging, I think the issue is related to curl:

On my mac (on which I am experiencing the issue), the following command fails:

curl -v --compressed --location --request GET \
     --header "Authorization: Bearer xoxc-..." \
     --header "Cookie: foo=bar" \
     --header "Cookie: d=xoxd-..." \
     --url https://slack.com/api/rtm.connect?mpim_aware=1&presence_sub=true

• On my Linux machine, the exact same command succeeds
• On my Mac the command will succeed if I remove the dummy "foo" cookie

So there seems to be some sort of differences between curl versions in how they send up multiple cookie headers.

My curl info from my mac (repeated here for convenience):

curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

My curl info from my Linux machine (Pop OS 22.04):

curl 7.81.0 (x86_64-pc-linux-gnu) libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.11
Release-Date: 2022-01-05
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets zstd

[robert-m-johnson]

Hmmm, not so sure it's a curl problem after all; when running the command

curl -v --compressed --location --request GET \
     --header "Authorization: Bearer xoxc-..." \
     --header "Cookie: foo=bar" \
     --header "Cookie: d=xoxd-..." \
     --url https://slack.com/api/rtm.connect?mpim_aware=1&presence_sub=true

it works inside an ubuntu docker container on my Linux machine, yet fails when ran within an ubuntu docker container on my mac. Pretty stumped with this one! 🤔

[ieure]

So there seems to be some sort of differences between curl versions in how they send up multiple cookie headers.

Can you compare good / bad output with curl -vvv? That should show you exactly what's getting sent over the wire.

[robert-m-johnson]

@ieure I can't see any significant differences in the output; this tallies with the fact that it seems to be the machine I'm running on that's important, not the curl version I'm using.

I think this is related to the network monitoring/proxying software (Netskope) the company I work for is using (my mac is my work laptop, my linux machine is my personal laptop). Normally if that sort of thing causes a problem it just causes the connection to fail altogether, so this specific problem is a bit odd. But even so, it doesn't seem crazy to me that there's some proxy server somewhere that garbles the cookies if sent separately rather than all at once.

@benthamite Are you also using some sort of work-specific machine and/or connected via a corporate VPN (or similar)?

[benthamite]

@robert-m-johnson

No, I'm using my personal machine and am not connected via a VPN or in any other unusual way. Is there anything I can do to help diagnose the problem?

[isamert]

I also realized that I have that problem in my mac machine (which I also use for work, I've changed my workflow a bit lately, that's why failed to realize this does not work on mac). Upon investigation (thanks @robert-m-johnson for his great debugging information) I realized it's totally related to curl version, at least in my case. I've found out that I got two different curl binaries in my system (I don't know why):

$ /opt/local/bin/curl --version
curl 7.78.0 (x86_64-apple-darwin20.6.0) libcurl/7.78.0 OpenSSL/1.1.1l zlib/1.2.11 zstd/1.5.0 libidn2/2.3.2 libpsl/0.21.1 (+libidn2/2.3.2)
Release-Date: 2021-07-21
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IDN IPv6 Largefile libz NTLM NTLM_WB PSL SSL TLS-SRP UnixSockets zstd

$ /usr/bin/curl --version
curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport) LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
Release-Date: 2019-03-27
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

request.el was using the former one and indeed the request that @robert-m-johnson mentioned was not working with it:

$ /opt/local/bin/curl -v --compressed --location --request GET \
     --header "Authorization: Bearer xoxc-..." \
     --header "Cookie: foo=bar" \
     --header "Cookie: d=xoxd-..." \
     --url https://slack.com/api/rtm.connect?mpim_aware=1&presence_sub=true

{"ok":false,"error":"invalid_auth"}

But the exact same request with the /usr/bin/curl is working flawlessly. I also installed curl through brew and it also worked (It installs the curl binary under /usr/local/opt/curl/bin/curl). Here is the version information for the brew installed curl:

$  /usr/local/opt/curl/bin/curl --version
curl 7.84.0 (x86_64-apple-darwin20.6.0) libcurl/7.84.0 (SecureTransport) OpenSSL/1.1.1q zlib/1.2.11 brotli/1.0.9 zstd/1.5.2 libidn2/2.3.2 libssh2/1.10.0 nghttp2/1.48.0 librtmp/2.3 OpenLDAP/2.6.2
Release-Date: 2022-06-27
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

After doing

(setq request-curl "/usr/bin/curl") ;; or "/usr/local/opt/curl/bin/curl" for the brew installed one if you don't have this in your system

emacs-slack started working on my mac machine.

I know that this does not answer the following

it works inside an ubuntu docker container on my Linux machine, yet fails when ran within an ubuntu docker container on my mac. Pretty stumped with this one!

but maybe it's also related to the curl versions? Maybe one of the docker images was outdated or something like that?

[robert-m-johnson]

@isamert Interesting! I'm glad it's working for you.

Sadly, the same fix doesn't work for me. In fact I did try running the brew-built version (7.84) before I tried running it within a docker container, and that didn't work for me either. I re-installed and re-ran the the brew-built version just to be sure, but sadly I get the same issue. (I can verify that it's sending the newer curl version as part of the headers seen when using the -v switch, so I'm sure I'm selecting the correct binary).

I set up an Ubuntu VM (via vagrant) and tried using the debug curl request in there as well to take some more parts out of the equation, but sadly for me that still doesn't work.

So, I'm still pretty stumped - but the fact that you @isamert were able to reproduce and fix the issue does give me some hope that there's something within my control I could fix to get this to work on my work mac.

@ieure & @benthamite Could you please share your curl --version outputs?

[benthamite]

Coincidentally, I moved to a new laptop recently and Slack is now working fine! I'm not sure what changed, since it's the same operating system and, I believe, the same version (macOS Monterey), though the new machine has an M1 chip.

Here's my curl --version output:

curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

[jasonmj]

I'm getting this error now too. Here's my curl details:

curl 7.76.1 (x86_64-pc-linux-gnu) libcurl/7.76.1 OpenSSL/1.1.1l zlib/1.2.11 brotli/1.0.9 libssh2/1.9.0 nghttp2/1.43.0
Release-Date: 2021-04-14
Protocols: dict file ftp ftps gopher gophers http https imap imaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL TLS-SRP UnixSockets

[robert-m-johnson]

Latest Theory This is related to curl not using HTTP2 for some reason, even when the installed curl version supports it.

I had hoped that simply adding the argument --http2 to a curl call would result in a successful call on my mac (which is experiencing the issue), but sadly that doesn't work. Feels like we're slowly getting closer at least though...

Detail Digging into the verbose output given by curl, I spotted one difference that I hadn't noticed before which is that successful responses on my Linux machine included the lines

* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
...
> GET /api/rtm.connect?mpim_aware=1&presence_sub=true HTTP/2

whereas the corresponding lines for failing responses on my mac look like

* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* Info: ALPN, server did not agree to a protocol
...
> GET /api/rtm.connect?mpim_aware=1&presence_sub=true HTTP/1.1

On my Linux machine, I can then get the command to fail if I append the argument --http1.1. I hoped that on my mac I could force curl to use HTTP2 via the --http2 argument, but for some reason this still fails.

Interestingly, in both cases I can see the lines

* ALPN, offering h2
* ALPN, offering http/1.1

so the server is apparently offering HTTP2, and most current curl versions support it, yet HTTP1.1 is still ultimately chosen.

In isamert's earlier comment I notice that the HTTP2 capability was not listed for his version of curl which wasn't working. So that would explain why the curl version made a difference in that particular case.

So we still have a bit of a mystery to solve in those cases where curl --version reports support for HTTP2.... :thinking:

[robert-m-johnson]

@jasonmj Try running a test request of the form

$ /opt/local/bin/curl -v --compressed --location --request GET \
     --header "Authorization: Bearer xoxc-..." \
     --header "Cookie: foo=bar" \
     --header "Cookie: d=xoxd-..." \
     --url https://slack.com/api/rtm.connect?mpim_aware=1&presence_sub=true

within a Docker container for the latest Ubuntu version.

If that works, installing a newer version of curl may help.

If not, could you please report if you are aware of any proxy servers and such that may be affecting your request (e.g. are you on some sort of work laptop)?

[jasonmj]

@jasonmj Try running a test request of the form

$ /opt/local/bin/curl -v --compressed --location --request GET \
     --header "Authorization: Bearer xoxc-..." \
     --header "Cookie: foo=bar" \
     --header "Cookie: d=xoxd-..." \
     --url https://slack.com/api/rtm.connect?mpim_aware=1&presence_sub=true

within a Docker container for the latest Ubuntu version.

If that works, installing a newer version of curl may help.

If not, could you please report if you are aware of any proxy servers and such that may be affecting your request (e.g. are you on some sort of work laptop)?

@robert-m-johnson I went ahead and updated my curl by upgrading to NixOS 22.05. Now my curl is at 7.83.1 (up from 7.76.1), but emacs-slack still doesn't work.

[robert-m-johnson]

@jasonmj Try running a test request of the form

$ /opt/local/bin/curl -v --compressed --location --request GET \
     --header "Authorization: Bearer xoxc-..." \
     --header "Cookie: foo=bar" \
     --header "Cookie: d=xoxd-..." \
     --url https://slack.com/api/rtm.connect?mpim_aware=1&presence_sub=true

within a Docker container for the latest Ubuntu version. If that works, installing a newer version of curl may help. If not, could you please report if you are aware of any proxy servers and such that may be affecting your request (e.g. are you on some sort of work laptop)?

@robert-m-johnson I went ahead and updated my curl by upgrading to NixOS 22.05. Now my curl is at 7.83.1 (up from 7.76.1), but emacs-slack still doesn't work.

Thanks! Is your machine a work laptop, or are you operating under some kind of proxy? If not, would you mind running a test request inside a docker container?

Debug information you can provide here could be quite valuable, because I think so far everyone having issues is either

1. Running on a Mac
2. Running over a work proxy and/or VPN
3. Using an old version of curl.

So just the fact you’re experiencing issues on Linux makes yours an interesting case.

[jasonmj]

@robert-m-johnson I got emacs-slack working again by updating my token to the newer version (xoxc) and adding a cookie.

This is a personal laptop, no proxies. I tested ubuntu for you and found curl was not installed. When I installed it with apt-get, the location was /usr/bin/curl, not /opt/local/bin/curl. Still, my curl request succeeded as well.

[robert-m-johnson]

Coincidentally, I moved to a new laptop recently and Slack is now working fine! I'm not sure what changed, since it's the same operating system and, I believe, the same version (macOS Monterey), though the new machine has an M1 chip.

Here's my curl --version output:

curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1
Release-Date: 2021-09-22
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz MultiSSL NTLM NTLM_WB SPNEGO SSL UnixSockets

@benthamite Could you please:

1. Share your curl version info for your new M1 machine
2. On your old machine (i.e. where the request doesn't work), try running a test curl request with a docker container for ubuntu 22.04?

[benthamite]

@robert-m-johnson

1. Share your curl version info for your new M1 machine

What I shared above is the information for my new M1 machine.

2. On your old machine (i.e. where the request doesn't work), try running a test curl request with a docker container for ubuntu 22.04?

Unfortunately, I no longer have access to my old machine.

[ieure]

I'm open minded here, but I'm skeptical that the root issue here is curl versions, just based on cURL being a 26-year-old, widely used tool for a standard protocol, vs. emacs-slack being a relatively new, niche tool for a proprietary API that changes all the time. You know?

In any case, I have a single curl binary on my system, and this is its version:

curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1n zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3

I can successfully auth on the CLI with it:

curl -vvv -H'Cookie: d=xoxd-...' 'https://api.slack.com/api/rtm.connect?token=xoxc-...'

But registering a team with that info and calling slack-start continues to give an auth error.

If the problem exists within the realm of curl, it seems like it's how either emacs-slack or request.el invokes it. Since emacs-slack uses request.el, and request.el supports multiple backends, it's trivial to confirm or deny curl's involvement in the problem. If I eval:

(setq request-backend 'url-retrieve)
(slack-start)

I continue to get the auth error, even though curl isn't sending the request at all. This points to the problem existing within emacs-slack.

[isamert]

I can successfully auth on the CLI with it:

curl -vvv -H'Cookie: d=xoxd-...' 'https://api.slack.com/api/rtm.connect?token=xoxc-...'

Are you able to authenticate with the following though?

curl -vvv -H 'Cookie: foo=bar' -H 'Cookie: d=xoxd-...' 'https://api.slack.com/api/rtm.connect?token=xoxc-...'

It's probably not a direct curl problem but seems like a problem related to the curl version, the slack api and your operating system combined.

[ieure]

I can successfully auth on the CLI with it:

curl -vvv -H'Cookie: d=xoxd-...' 'https://api.slack.com/api/rtm.connect?token=xoxc-...'

Are you able to authenticate with the following though?

curl -vvv -H 'Cookie: foo=bar' -H 'Cookie: d=xoxd-...' 'https://api.slack.com/api/rtm.connect?token=xoxc-...'

Yes, it works fine:

(edited somewhat)

$  curl -vvv -H 'Cookie: foo=bar' -H 'Cookie: d=xoxd-...' 'https://api.slack.com/api/rtm.connect?token=xoxc-...'
*   Trying 52.89.90.67:443...
* Connected to api.slack.com (52.89.90.67) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Slack Technologies, Inc.; CN=slack.com
*  start date: Mar 28 00:00:00 2022 GMT
*  expire date: Mar 28 23:59:59 2023 GMT
*  subjectAltName: host "api.slack.com" matched cert's "*.slack.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5642039b25c0)
> GET /api/rtm.connect?token=xoxc-... HTTP/2
> Host: api.slack.com
> user-agent: curl/7.74.0
> accept: */*
> cookie: foo=bar
> cookie: d=xoxd-...
> 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 2147483647)!
< HTTP/2 200 

[rest of the response elided]

[ieure]

It's probably not a direct curl problem but seems like a problem related to the curl version, the slack api and your operating system combined.

Also, as I mentioned, the problem continues to happen even with request.el set to use url-retrieve instead of curl. Therefore, it can't be purely a curl problem, since it still happens when curl isn't used.

While I know that some have seen emacs-slack work after messing with curl, this could be a side-effect and not the root problem. It initially worked for me, then stopped, so I see no reason why the problem can't be that it works intermittently, and messing with curl versions coincided with it beginning to work again, and that it may stop working for those folks at a later date.

[robert-m-johnson]

It's probably not a direct curl problem but seems like a problem related to the curl version, the slack api and your operating system combined.

This is a great summary of the issue. Moreover, Slack say that authenticating using xoxc tokens is not officially supported, so it would not be surprising if their API is non-compliant for certain (otherwise valid) requests. So overall I would say that emacs-slack may not be doing anything wrong per se, but some tweaks to how it behaves may work around some issues.

Also, as I mentioned, the problem continues to happen even with request.el set to use url-retrieve instead of curl. Therefore, it can't be purely a curl problem, since it still happens when curl isn't used.

I tried using url-retrieve as the backend on my Linux machine and emacs-slack didn’t work, whereas it works flawlessly for me when using curl. Slack uses HTTP2 and websockets, and that combined with the fact that url-retrieve is not a complete drop-in replacement for curl means that it is not surprising that emacs-slack fails when using url-retrieve, and therefore we can’t read too much into that failure.

@ieure it’s a bit of a stab in the dark, but maybe try deleting your cookie cache (~/.emacs.d/.cache/request/curl-cookie-jar)