failure getting salts during login

[shifting-earth]

Version Info
Plugin Version: 1.10.0
Kodi Version: 20.02
Operating System: Ubuntu 22.04

The Issue
I have entered my username and password. When I click on Subscriptions, Following, etc. I get "Rumble Error: check the log for details".

To Reproduce
Steps to reproduce the behavior:

1. Enter username and password
2. Click Subscriptions

Additional context
This addon was working well for me on 1.9.4 until about 3 weeks ago. I waited until a new version was released hoping that would fix the issue. I upgraded to 1.10.0, but the same error remained. I am attaching the debug log.

kodi_rumble_error.log

[azzy9]

Hi @shifting-earth,
I just tested on my side and is working as intended.
I haven't tested this plugin on Ubuntu, so will need to when I get a chance.
It is possibly related to #57.

If Cloudflare protection has been triggered, the only quick fix for this is to use flaresolverr.

[shifting-earth]

Thanks for your response.

I had tracked it down the the get_salts function in rumble_user.py.

It looked to me that the request to get the array of salt values was not coming back with anything. For example, if I make this request from the command line:

$ curl -X POST https://rumble.com/service.php?name=user.get_salts --data '{"username": "<>"}' --header 'Referer: https://rumble.com' --header 'Content-Type: application/x-www-form-urlencoded'

I get:

{"data":{"salts":false}}

In looking at the code, if that function returns False, then the login will fail.

Are you able to make a stand-alone requests and get the salt values? Is my curl command correct?

[azzy9]

Hi @shifting-earth,
I get the same results running that command in CURL.
I will need to test the plugin on ubuntu when I get time to see if it is the same.

[Geggin]

I have the very same problem on my Raspberry pi 4 with Debian Bookworm. I have tested reinstallation and even a complete new fresh system on another sdcard. Same results. I can see a request in the flaresolverr-log for https://rumble.com/service.php?name=user.get_salts, which fails

However it works from kodi on Windows and from kodi on my Google TV. In flaresolver there is no requests coming in for neither https://rumble.com/service.php?name=user.get_salts or https://rumble.com/service.php?name=user.login.

I have not fixed it but this is what I've come up with so far.

In general.py, lines 143-147 are the problem (I think)

  # make request
  if data:
      response = reqs.post(url, data=data, headers=my_headers, verify=False, cookies=cookie_dict, timeout=10)
  else:
      response = reqs.get(url, headers=my_headers, verify=False, cookies=cookie_dict, timeout=10) 

1. The addon makes a request to https://rumble.com/service.php?name=user.get_salts with data: {'username': 'myname'} which will end up on the reqs.post line. This call does not work on the rpi4. It always returns a 403 response. This causes the addon to try flaresolverr but that is not correct. The request should have worked and it is working from other systems.

While fiddling around in the code I got it working by changing the request to:
response = reqs.post(url, data, my_headers, cookies=cookie_dict)

Wohoo! response is now always a 200.

2. The addon then makes a call to https://rumble.com/service.php?name=user.login with the data: {'username': 'myname', 'password_hashes': 'hash1,'hash2,'hash3}. Again it is making a POST request and it too works (after the code change). Looking good!

3. I then click Subscriptions and the addon makes a call to https://rumble.com/subscriptions. This time with no data since login info is correctly stored in cookies. So now it does a GET request and this always fails and returns a 403 response. I have tried to change the code as I did for the reqs.post but I just cant get it to succeed. I have tried workarounds etc but nothing I do works. GET requests always return 403.

I have no clue why this is. Different python version? OS differences? Encoding issues?

[shifting-earth]

@Geggin , thanks for this analysis and confirming that is wasn't just me.

What python version are you running?

Mine is 3.10.12

[Geggin]

On PC: v3.9.13
On RPi4 i used to have v3.11.something but I just did yet another test-reinstall on a spare sdcard, now with Debian Trixie instead of a quite old Debian Bookworm.

Lo and behold! Now it works as expected right away. No code-hack needed.

...and oh:
On new RPi4: v3.13.5

[Geggin]

But I doubt that the installed python version matters that much. I think kodi embeds python library at compile time.

(not sure though)

[Slavegrid]

When I go to the Rumble website it seems to take the POST payload as a percent-encoded value, not as JSON. When I try to use the CURL command above that passes JSON I get

{"data":{"salts":false}}

If I change it to

curl -X POST https://rumble.com/service.php?name=user.get_salts --data "username=ms@slavegrid.com"

it returns

{"data":{"salts":["cVPx8xZM","24mbo4ypy","8GJGYAmY"]}}

Not sure if it is at all related. I'm running LibreElec on a Raspberry PI 4 without issue. It's also possible that different devices on the same network may or may not trigger Cloudflare challenges. They do analysis beyond just IP address. If it's going into the Flaresolverr block its because it detected a 403 with Cloudflare as the server returning the response which -- unless its somehow misdetecting -- implies that you reached the Cloudflare "press the magic button" page. Seems like you got Cloudflared and that Flaresolverr failed to work.

I suspect that perhaps the data is not being converted to percent encoded on the Flaresolverr call. So the people it works for are probably the people that are able to login without going through the Flaresolverr fallback.

You can try changing

flaresolverr_data['postData'] = data

to

flaresolverr_data['postData'] = urllib.parse.urlencode(data)

in lib/general.py line 78

[Geggin]

I do think it is very related.

There seems to be something weird going on behind the scenes when reading parameters. And I don't mean by the addon author, but in some version of some lib on some systems (?)

I was down the same train of though as you for a while, that there is something else going on that somehow affects kodi/addon. Or that people who got it working simply don't need to go through flaresolverr for user.get_salt.

However, I now think that the request to https://rumble.com/service.php?name=user.get_salts never gets cloudflare'd. For anyone, including us. When I did the code change for POST requests (such as user.get_salt) it always worked. When I changed it back it stopped working. Changing it again: worked.

It just looks like cloudflare is involved because somehow something got screwed up in the requests, causing a 403 response, which in turn triggered the addon to try flaresolver even though that is not the problem.

So when I got it always working for POST I though it would be easy peacy to fix it for GET also, but no.

[Geggin]

One way to reliably test it is to:

1. Go into the addon Settings
2. Do Reset Session in the Login tab.
3. Click OK (important)
4. Go into the addon Settings again
5. Click Test Login Details in the Debug tab
   this will cause a POST to https://rumble.com/service.php?name=user.get_salts and then another POST to https://rumble.com/service.php?name=user.login, both will succeed.
6. Click OK
7. You now have valid session and cookie values in your settings.xml, yay.
8. Now try to click Subscriptions
   this will cause a GET to https://rumble.com/subscriptions which always fails (for us). Always. Grrr...

[Slavegrid]

@Geggin

If this is the line you're running

reqs.post(url, data, my_headers, cookies=cookie_dict)

then my_headers will be passed to the json parameter and not the headers parameters. Which I think implies that you're basically not specifying any headers beyond the headers that requests would normally add. Not sure what happens when you specify both 'data' and 'json' at the same time since they seem mutually exclusive. Changing the headers could also potentially cause Cloudflare to trigger or not.

    def post(self, url, data=None, json=None, **kwargs):
        r"""Sends a POST request. Returns :class:`Response` object.

        :param url: URL for the new :class:`Request` object.
        :param data: (optional) Dictionary, list of tuples, bytes, or file-like
            object to send in the body of the :class:`Request`.
        :param json: (optional) json to send in the body of the :class:`Request`.
        :param \*\*kwargs: Optional arguments that ``request`` takes.
        :rtype: requests.Response
        """

        return self.request("POST", url, data=data, json=json, **kwargs)

What happens if you change that line to:

reqs.post(url, data, headers=my_headers, cookies=cookie_dict)

[Geggin]

Just a guess but maybe the signature for the def post method in sessions.py differs between python versions?

def post(self, url, data=None, json=None, **kwargs):

or

def post(self, url, data=None, **kwargs):

Unfortunately I can not verify this at the moment. The sdcard with the problem install is at my office atm. I can check tomorrow.

[shifting-earth]

The def post signature on my installation (problematic) is:

def post(self, url, data=None, json=None, `**kwargs):

Again, that's Xubuntu 22.04 with python 3.10.12.

Might be worth noting that Xubuntu 22.04 is based on Debian Bookworm.

[azzy9]

Is it okay if anyone could try v1.10.5 with flaresolverr disabled