Support query params in shortened URLs

[karntrehan]

Is your feature request related to a problem? Please describe.
A new shortened url is required for change in query params. This can be solved by supporting query params to our shortened urls.

Describe the solution you'd like
Shortened urls could be appended with a query param which would allow single url for all redirections to parent page.

Describe alternatives you've considered
Considered creating multiple shortened urls for each query param change

Additional context
We shall be taking up the development for the same.

[ChakshuGautam]

@karntrehan

Since this is a shortened URL, it would make the URL long (which is defeating the purpose). How I see this right now is that you need to provide additional metadata that can be transferred to the downstream long URL. Can you provide more details on if we control the URL in such a manner to be able to add more metadata in a middleware? This can be done using an SDK that controls how a URL gets utilized. Although this approach would fail when the URL is in an env that cannot be controlled.

Additionally if absolutely need to do this, can we restrict it to a single query param?

[ChakshuGautam]

If we are going to do this, should Yaus verify

1. the query param
2. the query param value

Both can be done through the regex before sending the request downstream.

[rahul10100]

Take a look at Google Tag Manager

…

On Fri, 3 Feb 2023, 14:27 Chakshu Gautam, ***@***.***> wrote: If we are going to do this, should Yaus verify 1. the query param 2. the query param value Both can be done through the regex before sending the request downstream. — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADI7N32VEJUQV7JL5W6ISHDWVTB6LANCNFSM6AAAAAAUP5GVTA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[yuvrajsab]

hey @ChakshuGautam, the url which we were refering was that metabase url http://X.X.X.X:3000/public/dashboard/3b59cc9d-7128-4ae8-9360-9f3dc78f7bab?student=123456. I don't think we have much control over how this url is getting generated. And yes for now we only need 1 query param which is 'studentid' in this case but in future there could be need for more.

[choxx]

If we are going to do this, should Yaus verify

1. the query param
2. the query param value

Both can be done through the regex before sending the request downstream.

I'd vote for this; it'll be an additional level of security. Shall we go ahead with this?

[yuvrajsab]

If we are going to do this, should Yaus verify

1. the query param
2. the query param value

Both can be done through the regex before sending the request downstream.

I'd vote for this; it'll be an additional level of security. Shall we go ahead with this?

I didn't get what @choxx and @ChakshuGautam meant by this "Yaus should verify and how this can be done using regex". We are using encodeURIComponent() function that will encode what every queryparam we throw at it. I think that should be fine.

[yuvrajsab]

Should be closed by #47. Need merging to master.