Skip to content

Entry ID's and 32 bit environment #1962

@Vincentv92

Description

@Vincentv92

Recently I ran into an issue when I migrated my FreshRSS installation from a 64 bit environment to a 32 bit environment. Specifically the use case when using the Fever API and the Reeder client for macOS and iOS.

It appears, that some entry id's for the articles have a very high number, as in for example 1531867867902117 as unique identifier.
For storing these entries on a 32 bit environment when using MariaDB or MySQL works perfectly fine since the id column is stored as a bigint.
But there are issue's within PHP handling these integers if the environment is 32 bit.
I only ran into issues with the Fever API since that's the only component I currently use extensively.

The issue

After migration my Reeder client's successfully downloaded the articles but failed to fetch new articles through the Fever API. So I opened up my Nginx access logs to see what happend. I saw I had around hundreds of requests per minute which looked something along the lines of this:

POST /api/fever.php/?api&items&since_id=1532025245261275 HTTP/1.1" 200 72900 "-" "Reeder/3010.29.01 CFNetwork/902.1 Darwin/17.7.0 (x86_64)"
POST /api/fever.php/?api&items&since_id=1532025245261275 HTTP/1.1" 200 72900 "-" "Reeder/3010.29.01 CFNetwork/902.1 Darwin/17.7.0 (x86_64)"
POST /api/fever.php/?api&items&since_id=1532025245261275 HTTP/1.1" 200 72900 "-" "Reeder/3010.29.01 CFNetwork/902.1 Darwin/17.7.0 (x86_64)"
POST /api/fever.php/?api&items&since_id=1532025245261275 HTTP/1.1" 200 72900 "-" "Reeder/3010.29.01 CFNetwork/902.1 Darwin/17.7.0 (x86_64)"
POST /api/fever.php/?api&items&since_id=1532025245261275 HTTP/1.1" 200 72900 "-" "Reeder/3010.29.01 CFNetwork/902.1 Darwin/17.7.0 (x86_64)"

So I went ahead and manually verified the returned data from the Fever API and noticed the id 1532025245261275 was the last element from the the Fever API response. At this point I wasn't sure what was happening, I compared this to my previous installation and it worked perfectly fine there.
The next thing I did was verifying that the findEntries function of the fever.php file was receiving the id 1532025245261275 and I noticed I saw the PHP_INT_MAX value 2147483647

This is where I got the aha moment. The cause was from this specific line

Possible solutions

The issue is that function intval() cannot use the big integers on 32 bit system, so my quick fix was to remove all intval() functions from the fever.php file to test if it worked again after that.
And yes that worked.

So there are a few solutions to this issue:

  1. Don't support 32 bit installations
  2. Make the entry_id's 32 bit safe (or configurable)
  3. Only validate its a valid integer but pass on the string value to the query builder and let the database handle this

So what should be a proper solution for this issue?

PS, I checked if there were more intval() usages within the project and noticed there are more references to this. Not all of them handle an entry id but this could potentially cause more issue's which haven't been noticed (yet)

Metadata

Metadata

Assignees

No one assigned

    Labels

    API 🤝API for other clients

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions