i've had a strange bug happening with a couple users in our environment that i finally managed to track down. before i submit a patch, i'd like to hear opinions about the best way to do so.
the problem essentially boils down to overly permissive google analytics(GA) cookies that some of our customers and end users are using. in some cases, GA hands out a cookie named _gid - that cookie can cause problems with roundcube if it's sent along as part of the request for retrieving contacts on the compose page.
if you are using a custom contacts souce (as is the case with a contacts plugin, ie the carddav one) in program/steps/mail/list_contacts.inc this block is evaluated:
if ($group_id = rcube_utils::get_input_value('_gid', rcube_utils::INPUT_GPC)) { $CONTACTS->set_group($group_id); }
the request comes in from a GET, but rcube_utils::INPUT_GPC causes rcube_utils::get_input_value() to also consider cookies. if the GA _gid cookie is present, things fall apart (as the value of the cookie does not correspond to an existing group) and no contacts are returned.
the simplest fix would be to switch rcube_utils::INPUT_GPC to rcube_utils::INPUT_GET so that roundcube would not consider the cookie. but, there could be some historical use case where the cookie needs to be considered?
as an alternate, list_contacts.inc could try and validate the content of the $group_id that is returned and skip setting it if it doesn't seem reasonable.
it would seem a little ugly to specifically check for a google specific cookie in the code, so it seems like the INPUT_GET change would be better... but i don't know if that would break other plugins.
thoughts?
On 12/08/2017 09:18 PM, Brendan wrote:
i've had a strange bug happening with a couple users in our environment that i finally managed to track down. before i submit a patch, i'd like to hear opinions about the best way to do so.
It's been already fixed in the core of 1.3.0. https://github.com/roundcube/roundcubemail/issues/5748.