Ripcord Dev Logo Ripcord Development — View Ticket Login or Create Account
Ticket UUID: 22f1e95655945035ab5acc7c8419763894af47c7
Title: Slack SSO Login via Importing HAR file not working
Status: Closed Type: Feature_Request
Severity: Minor Priority: Low
Subsystem: General Resolution: Unable_To_Reproduce
Last Modified: 2019-08-07 02:30:00
Version Found In: Ripcord: 0.4.11 / Slack: 4.0.1
ymi2019-08-04 00:32:25

I've got access to another Slack instance that has SSO using Okta. When I export the HAR file from Chrome, it can't find all the details it's looking for ("Couldn't find Slack account credentials data in this HAR file"). I've tried exporting it a few times, but it always gives the same error. Here are the details:

  • Authorization token: found
  • Cookies: found
  • Workspace domain: not found
  • User name: not found
  • Team name: not found
  • User ID: not found
  • Team ID: not found

I suspect that not all SSO/SAML providers provide the same headers. Either that or Slack did another breaking change instead of adding features users care about. Like dark mode.

It might be worthwhile to have the HAR loading fill out a form that can be hand-edited, and show some example values of what the data in that field is supposed to look like and other requests that might have it. That way if something breaks, we can help track where the data is.

cancel2019-08-04 01:31:46

What version of Chrome are you using? Does this happen for all of your SSO workspaces now, or just this one? (Can you try the others you have and see if they have stopped working?)

ymi2019-08-04 21:38:25

Chrome version was 75.0.3770.142. Checking of course triggered an update. Yay for Chrome.

None of my other instances are SSO. It's just this one, really, but it'd be jumping the gun for me to assume that everything's broken just because my use case doesn't work.

That said, I tried using the HAR (export from Chrome, browse and import into Ripcord) from one of my non-SSO instances and got the same issue. It only found the auth token and the cookies, but not the rest. That leads me to think that maybe it's a Slack-wide change.

cancel2019-08-05 03:35:24

That's odd. Because it still works for me. On both SSO and non-SSO workspaces. That's why I suspect it's a change in Chrome, or something. Or perhaps your user account is in some A/B test rollout? Can you try it with another browser, like Firefox?

ymi2019-08-05 05:54:21

Done. Firefox 68 had no problem exporting the HAR and Ripcord was able to import it. So it's definitely something weird with Chrome. I pulled the two HAR files up in Winmerge and the formatting is of course substantially different. I don't know what it's looking for, though, so I can't give any direction based on that.

If you want to let me know which info headers/keys it's looking for, I'll use the values of them in Firefox to look for something corresponding to it in Chrome. We can also just close it if you think this is good enough.

cancel2019-08-05 06:08:58

I tested with Chrome, and it still works for me. I have a bunch of code in Ripcord that looks in all of the places that every popular browser uses. (For what it's worth, it's looking in the response bodies for the info that you're missing, not in headers.)

Are you sure you're expoting "client.boot" and not some other request? I saw recently that "client-boot-blahblah" type requests show up in Chrome now (they're from service workers, whatever those are.).

ymi2019-08-06 13:32:48

Yes, it's client.boot. After opening the tab, dev tools and switching to Network and XHR tabs, I always hit F5 to refresh and https://x.slack.com/api/client.boot?_x_id=noversion-y&_x_version_ts=noversion&_x_gantry=true request is near the top of the XHR list. (x and y being identifier replacements) No files starting with client-boot show unless I explicitly go out of the XHR tab to find them.

Just in case I was being careless previously, I opened up the old non-functional HAR from the 3rd and the request URL is saved inside. Path is $.log.entries[22] on mine to find the entry object containing the POST request out to client.boot. The Firefox HAR shows it at $.log.entries[1]. Chrome 75's was a 13MB HAR file, and Firefox's was 344KB. Maybe that version was saving more data than it was supposed to?

I've restarted Chrome since the update, though, (76.0.3809.87) and deleted the account in Ripcord, exported from Chrome and added to test and now it works. ¯\_(ツ)_/¯

I have no idea why it went all Heisenbug on me, but it's working now. It wasn't the first time I tried it, but it was the time I filed an issue for it.

cancel2019-08-07 02:29:37

Ok. Thanks for doing all of that.

I don't know why it didn't work. Anyway, it doesn't matter what order the fields are in or what their indices are or any fiddly stuff like that. Ripcord scrapes the entire contents of the file looking for the data it needs.