PrivacyDevel/nitter

Tokens not being read even after following example.conf

Closed this issue · 9 comments

To explain, in brief, it seems that no matter what I do, the configuration isn't being taken properly. I was suspecting that it was something that I missed but after comparing config with a buddy who's also hosting the same fork, I'm not quite sure anymore.

I'll recount my steps here to show you my process of building and deploying the fork to see if anything comes up to you here.

I began with cloning the repo with a git clone so I could build the image. docker build -t privacydevel/nitter:latest .
I let the image build and then copy/pasted the dockercompose.yml while replacing the image parameter with the image that I built from your fork. The only other things that I edit in the .yml are the ports and the volume path (to point to the nitter.conf file).

I copy over the nitter.example.conf and verify that it's being read by pointing the container to it in the docker compose file. Changing values like "title" is reflected in my nitter instance so the container is reading config just fine.

I have a twitter account that I've set to allow for the searching and viewing of sensitive content.
Accessing https://twitter.com/settings/search gives me this:
Screenshot_06-11-2023_05:09

Likewise, Settings and Support > Settings and Privacy > Privacy and Safety > Content you see:
image

With an inspect element (chromium browser), I grab the values needed for ct0, auth_token and xCsrfToken. ct0 and auth_token I got from the application tab while xCsrfToken I grab from a request header in the network tab.
Double-checking myself, I read through the issue that was posted here earlier where someone had whitespace in their configuration, which caused their search to not work (as well as R18 content to not be displayed). Their symptoms are similar to mine, though there wasn't any whitespace in my configuration like how the other person's was.

This is what the tokens look like in my config (the X'es are placeholders):

cookieHeader = "ct0=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; auth_token=XXXXXXXXXXXXXXX"
xCsrfToken = "XXXXXXXXXXXXXXXXXXXXXX"

Outside of this, I've double-checked for any issues with firewalling and file permissions. Between myself and my friend who's running the same fork, we compared configs, set-up, etc and they're exactly the same. The main differences between me and him that I could find (if significant at all) are that:

  1. I'm running the docker container in a proxmox VM (Debian 11, amd64).
  2. The account that I'm using for its cookies is a private account.

On that last one, I've checked with a non-private account to see if that'd make any difference (it didn't). Other details that might be relevant is that I'm proxying the host with NIGNX, though symptoms still persist whether by connecting via the proxy or directly through the IP and port of the machine.

I hope I'm not missing something obvious. I've been trying to see if it's something that I missed but I think I've exhausted my options with about as much as I know to do, currently.

An addendum: checking docker logs also don't reveal anything significant either:

Starting Nitter at https://nitter.<site>.<tld>
Connected to Redis at nitter-redis:6379

Thank you for your detailed bug report. Could you please open your about page at http://your_instance/about and check the version on the bottom of the page to make sure that you are actually running the most recent version of this fork?

I'm on the most recent version of the fork. Checking the about page shows me that I'm on this version 2023.06.06-25b7884, which aligns with your most recent commit.

When you open a profile page, does it show the "Likes" tab? If so, then it does detect the variables.
What exactly isn't working and how does it fail? Did you logout of your account on that browser after getting those tokens? Maybe they have been invalidated because of that?

Sorry for the late response here. No, I don't see the likes tab in any profiles that I browse.

Also, no, I'm not logging out with the tokens at all, though that does give me an indicator to where an issue may arise. I start a private window to log into the account with to grab my tokens. I would have assumed that, even with closing out of the private window, the tokens would still be valid, given that I've done similar for different applications with no major issues. I'll test this out with a non-private window for once and will report on if it makes a difference or not.

After doing that, there's no difference unfortunately.

Something else that comes to mind... From what I understand too, the ct0= and xCsrfToken should be quite similar to each other, if not, are the same exact value yes? I've already tried grabbing them from their respective locations and also copying over the ct0 value to xCsrfToken with no changes to Nitter.

You can just copy those values from a private window and let the browser get rid of them later, yes. As long as you don't log out explicitly yourself that should be fine. And yes, xCsrfToken and ct0 are in fact identical. I wasn't sure initially but now after I've done it with multiple accounts I can confidentially say that they actually always are the same.

Since the "Likes" tab doesn't show up, that means that the cookieHeader or the xCsrfToken line must be invalid.

That tab is supposed to appear as long as those values are supplied, even if they were to be invalid.

Are those lines in below the [Config] line but not under [Preferences]?

Yep, they're under [Config] but not under [Preferences].

That being said, I just found out what the issue was. TL;DR: user error

It's a bit embarrassing to admit, but I found a random break in a line earlier in the config at nitter.conf (specifically the key that I threw into hmacKey). I was about to send a screenshot to see if you would have noticed anything amiss in my config but doing so made it stand out to me immediately. Fixing that break made the Likes tab appear and now NSFW content is showing.

At the very least, thank you for your time, it was appreciated