Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API Invalid query parameter provided #25722

Open
Monschichi opened this issue Jun 2, 2022 · 4 comments
Open

API Invalid query parameter provided #25722

Monschichi opened this issue Jun 2, 2022 · 4 comments

Comments

@Monschichi
Copy link

Description:

With 4.8.0, at least, the user-list API doesn't work anymore as expected. With 4.7.1 it worked.

Steps to reproduce:

  1. use example query https://developer.rocket.chat/reference/api/rest-api/endpoints/team-collaboration-endpoints/users-endpoints/get-users-list

Expected behavior:

response like documented

Actual behavior:

{"success":false,"error":"Invalid query parameter provided: \"{ active: true, type: { $in: ['user', 'bot'] } }\" [error-invalid-query]","errorType":"error-invalid-query","details":{"helperMethod":"parseJsonQuery"}}

Server Setup Information:

  • Version of Rocket.Chat Server: 4.8.0
  • Operating System: Debian buster
  • Deployment Method: tar
  • Number of Running Instances: 2
  • DB Replicaset Oplog:
  • NodeJS Version: v14.18.3
  • MongoDB Version: 5.0.8

Client Setup Information

  • Desktop App or Browser Version: curl
  • Operating System:

Additional context

curl --location -g --request GET 'https://XXX/api/v1/users.list?query={ active: true, type: { $in: ['\''user'\'', '\''bot'\''] } }' \
--header 'X-Auth-Token: XXX' \
--header 'X-User-Id: XXX'
{"success":false,"error":"Invalid query parameter provided: \"{ active: true, type: { $in: ['user', 'bot'] } }\" [error-invalid-query]","errorType":"error-invalid-query","details":{"helperMethod":"parseJsonQuery"}}

Relevant logs:

[2022-06-02T10:29:13.796Z] WARN (API/6045 on XXX01): attribute query is deprecated
[2022-06-02T10:29:13.797Z] WARN (API/6045 on XXX01): Invalid query parameter provided "{ active: true, type: { $in: ['user', 'bot'] } }": {}
@ankar84
Copy link

ankar84 commented Jun 15, 2022

Confirm that issue on 4.8.1
Some scripts are broken.

@r-souza
Copy link

r-souza commented Jul 1, 2022

Confirm on version 3.8.17 too

@markusstoll
Copy link

Could it be that commit 31ae30f
by @ggazzo
changed things in a way that some queries do no longer work?

For me searching for customFields e.g. { "customFields.pkey" : { "$eq" : " + "my value"}}
gives a
Invalid query parameter provided: "{ "customFields.pkey" : { "$eq" : " + "10221"}}" [error-invalid-query] (this still worked on 4.7.2)

and querying for all fields using {"_id": false, "value": false} (according to https://developer.rocket.chat/reference/api/rest-api/endpoints/other-important-endpoints/query-and-fields-info#query-example) does no longer work too.

nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Aug 28, 2022
SAPI's find_rc_user_by_sapi_user_id is now failing
    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

I believe this is related to
	RocketChat#25722
	"API Invalid query parameter provided"
and caused by
	commit 31ae30f
	RocketChat#25648
	"Chore: Rest API query parameters handling"
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Sep 5, 2022
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

		`/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the issue

		RocketChat#25722
		"API Invalid query parameter provided"

and is caused by

		RocketChat#25648
		"Chore: Rest API query parameters handling"
		commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Sep 12, 2022
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Sep 13, 2022
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.
@tassoevan tassoevan added type: bug and removed bug labels Oct 26, 2022
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Aug 2, 2023
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Aug 10, 2023
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Aug 31, 2023
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Nov 29, 2023
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Dec 4, 2023
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Dec 4, 2023
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Feb 6, 2024
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Feb 9, 2024
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
nmagedman added a commit to seekingalpha/Rocket.Chat that referenced this issue Apr 4, 2024
SAPI’s `find_rc_user_by_sapi_user_id` calls RC’s `users.list` API endpoint with

    `/api/v1/users.list?query={"customFields.sa_id": #{sapi_user_id}}`

This call fails under vanilla RC 4.8.4 with

    Error: Invalid attribute: customFields.sa_id [error-invalid-query]
    at Object.get (app/api/server/v1/users.js:330:11)

This problem is related to the Upstream issue RocketChat#25722

    "API Invalid query parameter provided"

and is caused by Upstream PR RocketChat#25648

    "Chore: Rest API query parameters handling"
    commit 31ae30f

which limited which MongoDB query filters may be passed in via the RC API.
That PR was correct to restrict the query, but did not whitelist enough fields.
SAPI’s current integration with RocketChat depends on `customFields` being exposed.

Security Considerations:
Although none of SAPI’s customFields contain sensitive data, other RC installations
might indeed store sensitive data there.  It’s not clear, therefore, whether this
patch should be PR’d upstream.

=====

UPDATE:
Apparently Upstream wasn't didn't share my security concern.  They accepted
a PR that was identical to one of the two changes that were here, namely
    apps/meteor/app/api/server/v1/users.ts
    ```
           inclusiveFieldsKeys.includes('name') && 'name.*',
           inclusiveFieldsKeys.includes('type') && 'type.*',
    +      inclusiveFieldsKeys.includes('customFields') && 'customFields.*',
         ].filter(Boolean) as string[],
    ```
See https://github.com/RocketChat/Rocket.Chat/pull/27423/files

My patch also has a second change, adding customFields to
    apps/meteor/app/api/server/lib/users.ts#getNonEmptyFields()
Since it wasn't included in the upstream PR, maybe it isn't actually needed?
I'm keeping it for now, but we should experiement and see if we can safely drop it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants