Comments

You should update to a version without know security issues. If you do, you would find that piece of information in the API description:

dateInserted

string

(query)

When the user was created. This filter receive a string that can take two forms. A single date that matches '{Operator}{DateTime}' where {Operator} can be =, <, >, <=, >= and, if omitted, defaults to =. A date range that matches '{Opening}{DateTime},{DateTime}{Closing}' where {Opening} can be '[' or '(' and {Closing} can be ']' or ')'. '[]' are inclusive and '()' are exclusive.

The current version allows e.g. /api/v2/users?page=1&limit=5&dateInserted=(2019-06-13,2019-12-14).

Discussion works as expected because that endpoint is "public": I assume you don't need any permissions at all to view that data. Fetching discussions therefore isn't an indicator if authentication is working properly

You have said, that you were able to fetch users, but that the dateInserted parameter did not work. But you've also said, that you are on version 2.8.4... Look at /applications/dashboard/controllers/api/UserApiController.php if the "dateInserted" is already implemented in your version. If not, you know the reason why you can't make it work.

If it is already implemented in 2.8.4 but it is not working, well, I don't want to be impolite but I personally would think it is a waste of time implementing a feature into an old and insecure installation when an update would be enough (and is highly recommended anyway). Sorry.

That said, if you insist on your old installation and need to get that list of users, ask yourself if that information must be requested in exactly that way. Writing a plugin which provides that information is trivial. That's one option.

public function usersApiController_indexOutput_handler($input) {
// Write the result to UserMeta to inspect it
Gdn::set('debug_filter', dbencode($input));
$output = some array magic to transform $input
return $output;
}

But in that case you would have to intercept the request to ensure that the filter is only applied when you are requesting that information and not for every request, since that could damage the functionality of your forum

I know this is an "old" version, but the last minor release with a security fix was made in June, not 2 years ago.

At first I wanted to upgrade to 3.2 in the last weeks (I know version 3.3 was released recently) but since I had several problems on upgrading from my previous versione (2.3.1), I decided to try with the last release of the major 2, and despite a few problems everything is now working as expected, .. except for the argument of this thread.

After that I also discovered that my production env has got PHP 7.1 and MySQL 5.5, and upgrade the server is not an option, so I hope that 3.3 requires those at minimum if I try again to upgrade (this time from 2.8.4 and not 2.3.1). I'm pretty sure I'm ok with PHP, but do not have an idea with MySQL. [update: just find here: https://docs.vanillaforums.com/developer/installation/self-hosting/; I should have problems I guess]

I guess I'll give the update another try, just to follow the right steps instead of trying a different path like developing a plugin.

Looks like upgrading will become a bigger issue for you in the very near future. I would recommend to try updating into a test installation. There are no problems that couldn't be solved while upgrading

After you have activated such a plugin you could post secret=(that monster from above or whatever you've set there)&dateInserted=2019-11-01 to yourforum.com/plugin/getusers and in return get the new users.