We are trying to make request to https://tty1.auth0.com/login?client=xxx&_tty1_utm_source=p&xxx and get the value of _tty1_utm_source out from a rule.
However when we are inspecting the value of context.request.query, the key _tty1_utm_source in the url becomes _tty_1_utm_source in the query object. This implicit change impacted how we will set key or get the value a lot.
May I know if this is a bug or there’s a reason?
I reproduced the issue and I’m currently reviewing the situation; as soon as I have additional information I will give you an update. The issue seems constrained to parameters with mix case or containing numbers; if you have the possibility to avoid those two situations then you can workaround this for now.
At this time due to the current way Auth0.js v8 works any parameters sent to the hosted login page will end up being converted to snake_case (and number are considered as an independent term so param1 will be seen as param_1 in the rule). The reason for this is that Auth0.js v8 performs the snake case of any additional parameters by default which would not be so unexpected if you also used Auth0.js to initiate the original request to /authorize (calling the webAuth0.authorize method would send the parameter already in snake case).
However, if you manually navigate to /authorize?param1=true the parameter will end up being changed during the additional processing required to complete the authentication due to a side-effect of using Lock (it uses Auth0.js indirectly) or Auth0.js within the HLP itself.
Given that changing this would be a possible breaking change to existing code that may already accommodated to the current behavior we are not considering any change to this behavior within the Auth0.js v8 scope. However, this is something that will be reviewed in the next major version; thanks for bringing this to our attention.