Replace tokens with guest accounts, swap endpoints #985
No reviewers
Labels
No labels
accessibility
bug
discussion
documentation
enhancement
feature parity
good first issue
help wanted
question
rss
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
PAS/nitter!985
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "guest_accounts"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This replaces the old method of using guest tokens with using "guest accounts".
For more information see this comment https://github.com/zedeus/nitter/issues/983#issuecomment-1683134811
Live now on nitter.net for testing. If you'd like to test and don't have any guest accounts, feel free to reach out to me on Matrix. A way to acquire guest accounts will be build and shared very soon.
RSS returns forbidden, was this disabled?
https://github.com/zedeus/nitter/issues/937
hi @zedeus, this is amazing, just a question, how is guest_accounts.json formatted?
It's a JSON array of the raw object you get from guest account flow, looks like this (you can use this one for testing if you want):
Great! thanks a lot, it's the format from BANKA's script in an array.
I'm getting an error on compilation with this branch though, do you know anything about it?
parserutils.nim(39, 13) Error: undeclared field: 'notNull' for type packedjson.JsonNode [type declared in /Users/user/.nimble/pkgs/packedjson-#9e6fbb6/packedjson.nim(115, 3)]This happens with Nim versions older than 1.6.14, I'll fix it soon, for now you can work around it by updating to 1.6.14 or preferably 2.0
For the record: I successfully built a Docker image for aarch64 from this branch and it works like a charm :)
I changed the base image to use alpine 3.18 which has Nim 1.6.14
Sorry for the long post, couple of questions just for my own learning:
i.e. (this account is blocked now) ->
{"cookie":"_twitter_sess=xyz; kdt=xyz; auth_token=xyz; ct0=xyz; personalization_id="xyz"; twid="xyz, "x-csrf-token": "xyz", "authorization": "Bearer AAAAAAAAAAAAAAAAAAAAAxyz", "x-twitter-auth-type": "OAuth2Session", "x-twitter-active-user": "yes"}
I used a virtual machine to listen to network requests, but most of the reverse engineering work was done by other folks.
I'm not sure what you mean since that's how it already works, storing guest accounts in a file. No endpoints are being used beyond the initial creation of the account, which expires after 30 days. When you say blocked, do you mean you get an error code 88 (rate limit exceeded)? That block goes away 24 hours later.
Would you mind sharing what the kind of vm you use for this? something like wireshark or mitmproxy?
That's an actual burner account, not a guest account. It would be great if we could switch from guest to burner accounts like PrivacyDevel uses. In case it gets shut down again just have a few burners to still be able to use Nitter while finding a new solution.
By locked I mean:
"Twitter responded with an error: AuthorizationError: Authorization: Denied by access control: To protect our users from spam and other malicious activity, this account is temporarily locked. Please log in to https://twitter.com to unlock your account."
I used the free trial from Corellium to run Twitter and inspect network logs. I tried running BlissOS via qemu to no avail first.
I just noticed the thing you posted is a normal account, didn't look close enough. What I said still stands for guest accounts, they don't get blocked though just limited for 24 hours. The problem with burner accounts is you need a lot for any meaningfully big instance, so it's not really feasible especially since they just get locked. It's extremely easy to get guest accounts, just takes a lot of proxies which are easy to get.
Great thank you!
Yes the problem with guest accounts solution is that twitter can still kill this method no?
Indeed, but that's the case with every solution. With accounts they can start banning or further restricting, there is no perfect solution.
How to upgrade to this version?
Git clone this branch and run the following commands again?
Correct, but you also need to get one or more guest accounts, otherwise nothing will work
I have this running on my instance and so far it's running great, haven't seen any issues so far. Getting gust tokens definitely the trickiest part, but being as Im just running a private/relay instance one guest user should cover it.
Thanks for getting this put together!
Is it possible to run this branch with an actual account? What are the tokens I need to extract from the real account to create the JSON file?
It might be possible but I haven't tried, there's no code in this branch for regular accounts as they use cookies and bearer tokens etc instead of oauth.
Do you happen to know the rate limits for with_replies? I am burning through the limit fast with replies but the timelines seems stable for my private instances. Overall this is working great.
I know what the rate limit is supposed to be, but what it actually is I don't know. The same question was just asked here: https://github.com/zedeus/nitter/issues/983#issuecomment-1687182471
Thanks. I'll keep it on timelines for now until I can get a proxy system setup.
There's any guide on how to get guest accounts?
@felipefalkiner see here: https://github.com/zedeus/nitter/issues/983#issuecomment-1681199357
TL;DR you have to run a script which will create a guest account for you. You can reliably get 1 per day per IP. You should change the last line to
console.log(JSON.stringify(account)), then you can put it in a JSON array (looks like[{"user": ...}]) in the guest_accounts.json file Nitter expects in the directory you run it from.For local/private instance, I propose to have nitter automatically create guest accounts and store it somewhere in the disk.
I think it should be enough for local usage to have at least just one guest account.
And for bigger instance (public ones), the owner can provide a guest accounts file, like already implemented in this PR.
That's the plan, except I'll host a guest account pool service that public instances (those in the wiki) can automatically connect to, so they don't need to worry about proxies or anything.
Thanks for that.
In case anyone know nothing about node:
guest.jsand paste that script's content (includingJSON.stringifychange))package.jsonwith the extact contents:{"type":"module"}cdto that directory and runnode guestThat will create the JSON object. Adapt it to a JSON array (maybe run the script from several IPs?), and add it to
guest_accounts.jsonon nitter's working directory.Adding onto this, I know next to nothing about node, but was able to get this working passing the proxy host:port to the script. In theory it should work but all proxies I tested today didn't work:
https://gist.github.com/cmj/79501b374e387aebe3a717b9e8edda04
And because node seems to still be foreign to me I wanted to break it out into a simple shell script:
https://gist.github.com/cmj/6e6f6cae51c28cf6e161ceba8d108dda
Here is the same but with using proxy option:
https://gist.github.com/cmj/6cb90eae1ed299ee050a2396e7ceaaaa
@cmj Thanks, that's much easier. That script should be included on the repository itself.
I have been running this branch with a few tokens for a few days already.. seems to be working well other than hitting "Instance has been rate limited." when viewing individual tweets.. is having more tokens going to solve this problem? Or are they rate-limiting my server IP?
If each token's going to last about a month, we probably should tag them with a generation date so we can rotate them out easily/automatically.
@mhkhung Yes, more accounts will help (they're not called tokens to avoid confusion). Keeping track of accounts and handling them better is on the todo list. This is all very much WIP.
To avoid the overload of public instances, I've built the last version committed ( Version [2023.08.31-84dcf49]).
After few days of usage of then branch with guest accounts, and the progressives builts, it's seems that everythings works well even if from time to time I got the message "Instance has been rate limited. Use [another instance]".
Now running this new configuration, I had few questions about guest accounts.
The right knowledge of the correct approach to guest accounts, based on yours knowledge and experiences, can be usefull to address accordingly further and future issues (not related to Musk X paturnies).
The questions that I have are:
- For the local instance there is a rule of thumb about the number of the guest accounts?
- There is a way to check what his the guest account in use by Nitter application in a running environment, to keep track of
the usage and of the rolling management of it?
- I've seen that the screen name of the guest account (generated using procedures like those created by @cmj) has the prefix
_LO_mmdd (with mm that specify the month and dd that specify the date of the creation date of the account),
those information are used to expire the account? If this is true the account generation process must be structured
accordingly, expiring the accounts after their issue time limit.
Thanks to all for the various usefull comments and to @zedeus for his great work.
Hi. Just deployed

guest_accountsbranch to my server (with 2 guest accounts). However, it seems to be running very slow.When I open a user's timeline, it takes several minutes for the pictures to fully load.
The log shows nothing. I forwarded the port directly to nitter, so this should not be a proxy issue.
The debug endpoint (
/.tokens) is also blocked when loading the images.Do you have any ideas? Could it be a locking issue?
No clue, if you're using Nginx it might be weird buffering behaviour or a low file/socket limit. Try adding this to the location rule:
Update: I'm not going to create an issue just for this.
Eventually I found out there's something wrong with my DNS setup. The name resolution sometimes hang for 5+ seconds, and blocked the whole thread (and other requests).
Old comment
I didn't use Nginx in the previous example. Instead, I SSHed into my server and set up a port forward, to allow Firefox to talk to Nitter directly.
I also tried using Nginx (with and without the above rules), but it is still very slow.
Just noticed that there are several timeouts in the logs:
Does this indicate that my server is rate-limited by Twitter (possibly at the socket level)?
This instance is accessible only by myself, and I use it only for normal browsing. It shouldn't hit the rate limit.
I'll try to capture and inspect some tcpdumps later.
That's 100% an issue with your setup. It works fine for everyone.
Could you create a new github issue for discussing that? this PR is already filled with many comments so discussing an unrelated problem will make things much worse.
@ -16,3 +16,3 @@requires "sass#7dfdd03"requires "nimcrypto#4014ef9"requires "nimcrypto#a079df9"requires "markdown#158efe3"this bumps your
requires nimtorequires "nim >= 1.6", nitter doesn't build anymore with nim 1.4.8 because of this.@ -16,3 +16,3 @@requires "sass#7dfdd03"requires "nimcrypto#4014ef9"requires "nimcrypto#a079df9"requires "markdown#158efe3"Nice catch, thanks. 1.6.0 was released two full years ago, so I think it's time to bump that anyway. Debian is on 1.6.14 and Ubuntu 23.04 is 1.6.10, so I'll set that as the minimum.
@ -16,3 +16,3 @@requires "sass#7dfdd03"requires "nimcrypto#4014ef9"requires "nimcrypto#a079df9"requires "markdown#158efe3"I have created a PR for that: https://github.com/zedeus/nitter/pull/1053
@ -16,3 +16,3 @@requires "sass#7dfdd03"requires "nimcrypto#4014ef9"requires "nimcrypto#a079df9"requires "markdown#158efe3"Ideally your CI should build nitter with this minimum version instead of some loose 1.x to catch this in the future.
Could you rebase against master in order to include this commit:
github.com/zedeus/nitter@b62d73dbd3?Thank you
What's the status of this? Can nitter itself at least run the guest script itself once a day to replenish the tokens?
I hacked myself a small script to auto generate guest accounts with the
guest_tokens.shscript and (properly) append created entries to aguest_accounts.jsonfile between[and]characters.guest_tokens.sh:generate_guest_accounts.sh:Now generated entries should be appended while maintaining proper JSON syntax, I also format the whole file with
jqfor readability.NOTE:jq,sedandcurlare required to be installed on your system.Finally you can use
crontab -eto schedule execution of this script to your liking in order to fully automate the process of account generation:Here is a sample script used for testing in order to simulate what
generate_tokens.shwould do:@y0nei JSONL is supported, you don't need to do all that. Just append each json object on a new line and name the file
.jsonlinstead of.json.It seems the script for getting guest accounts it broken now. And maybe they expired all those credentials, I only get what's already cached in my instance.
Same issue for me, I'm unable to generate any new guest accounts, all of my current ones got "expired" and I can only view what is cached on my instance.
Oddly I can view posts in Nitter again with my old tokens, but the guest token generation script still returns
undefined(possibly it's been less than a day since my last failed guest token generation during the Nitter outage?). Let's see how long until Twitter kills less manipulative frontends again.Even during the outage, I could view user profiles and old tweets, but expanding any tweet resulted in an error.
Can confirm, the token script fails, but I can read Nitter again, mostly. Seems hit and miss, the RSS feeds show the tweet, but I can't see the tweet responses for example.
Replaced by #1210
Pull request closed