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
Comments
Confirm that issue on 4.8.1 |
Confirm on version 3.8.17 too |
Could it be that commit 31ae30f For me searching for customFields e.g. and querying for all fields using |
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"
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
Client Setup Information
Additional context
Relevant logs:
The text was updated successfully, but these errors were encountered: