Pass url params in rewrites and redirects

[patleeman]

** Please describe which feature you have a question about? ** Rewrites and redirects

** Provide additional details** Hello, I'm trying to set up a 301/302 redirect from a path in my amplify application. i.e. /test to another domain i.e. https://example.com/test. The redirect works as expected, but if I try to add some url parameters, /test?utm_test=test the redirect strips the url parameter and redirects to https://example.com/test. With the 200 rewrite, url params don't get stripped.

I want /test?utm_test=test&utm_something=something -302-> https://example.com/test?utm_test=test&utm_something=something

I get /test?utm_test=test&utm_something=something -302-> https://example.com/test

Is there a way to pass along all the url parameters in one shot?

As a side note, I am trying to redirect the path including the trailing slash and excluding the trailing slash. i.e. /test and test/. I know you can use the regex route to do both i.e. </(\/test)(\/)?/> -> https://example.com/test but there doesn't seem to be a way to use path parameters with regex paths?

i.e. </(\/test\/<path_param>)(\/)?/> --> https://example.com/<path_param> or even a way to specify the regex match group? --> https://example.com/<regex[1]> or something like that.

Thanks for the help

[hzhenmin]

1 Currently we do not support redirect with query string, we have added the feature into our backlog 2 <*> can be used to redirect everything after path to another url example: Source: /test/<*> Target: https://example.com/<*> Type: 301/302

[patleeman]

@hzhenmin Thanks for the <> tip. I didn't know you could do that. 👍

We found a workaround for the querystring issue for now. Thank you.

[swaminator]

@patleeman could you share your workaround for other users who end up here?

[patleeman]

@swaminator sure thing.

I ended up doing a 200 rewrite to an endpoint I wrote that returned a 302 redirect to the domain I wanted with the url parameters appended.

Not the best solution but it works for now.

[JonVisc]

@hzhenmin , Re-asking the question that @patleeman asked.

If we use regex to get a capture group, can we reuse that group? </^([^\.]+(?<!\/))$/> will match for: /test

But not match for: /test/ /test.html

So if a user hits https://example.com/test is there anyway to say we want to redirect them to https://example.com/test/ using that capture group?

You mentioned the functionality of a query string in the backlog but I thought more generically it would imply anything in a capture group. Is there an update if that functionality will be out soon/is out but the documentation is lacking so we don't know the syntax?

Adding in my coworker @eisware

[berniedurfee]

This seems to be breaking OIDC callbacks, where the user is redirected from the IdP back to the app route like: https://myapp.com/implicit/callback?code=abcxyz

The user is then immediately redirected by Cloudfront to https://myapp.com/implicit/callback/ without the query parameters, which breaks the OIDC flow.

The only solution was to force a 200 back to index.html using the rewrite rule specified here: https://docs.aws.amazon.com/amplify/latest/userguide/redirects.html#redirects-for-single-page-web-apps-spa

Though, it's not clear how that's working, without seeing the underlying Cloudfront configuration. It simply stops executing the 301, which preserves the query parameters.

@hzhenmin what's the solution proposed to allow redirects while preserving query parameters in Amplify?

[poolieweb]

+1 , We are trying to do RegEx with capture groups. Very difficult to replicate redirects from existing systems.

[awilkins]

Is this feature implemented with a Lambda@Edge? Maybe if we could get access to the source it would become clearer to people?

[SudduK]

This seems to be breaking OIDC callbacks, where the user is redirected from the IdP back to the app route like: https://myapp.com/implicit/callback?code=abcxyz

The user is then immediately redirected by Cloudfront to https://myapp.com/implicit/callback/ without the query parameters, which breaks the OIDC flow.

The only solution was to force a 200 back to index.html using the rewrite rule specified here: https://docs.aws.amazon.com/amplify/latest/userguide/redirects.html#redirects-for-single-page-web-apps-spa

Though, it's not clear how that's working, without seeing the underlying Cloudfront configuration. It simply stops executing the 301, which preserves the query parameters.

@hzhenmin what's the solution proposed to allow redirects while preserving query parameters in Amplify?

Hi berniedurfee,

Did you resolve the issue with OIDC callback url not preserving parameters?

I am trying to implement OKTA authentication (OIDC) for a React based SPA and trying to host the application into AWS Amplify (I tried initially to host SPA in S3 as static website along with Cloudfront and had PKCE errors not supporting http protocol with S3 website endpoint and eventually ended trying to use AWS Amplify)

When deployed to AWS Amplify, application tries to authenticate initially, but redirecting back to callback url (https://domainname.com/implicit/callback) seems to be not routing to the react callback component. I tried using a hack to rewrite the callback url, https://domainname.com/implicit/callback to https://domainname.com/#!implicit/callback in order to route to the Logincallback component, but missing code and state parameters which are required to complete authentication.

Secondly, I was not able to use the regular expression (</^[^.]+$|.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>) redirect for SPA successfully as given in AWS amplify documentation. This redirect rule is working only until redirecting the callback url to index.html and does nothing after that.

Any thoughts on how to approach this issue? Thank you!

Regards, Sudharshan.

[bighoot]

This seems to be breaking OIDC callbacks, where the user is redirected from the IdP back to the app route like: https://myapp.com/implicit/callback?code=abcxyz

The user is then immediately redirected by Cloudfront to https://myapp.com/implicit/callback/ without the query parameters, which breaks the OIDC flow.

The only solution was to force a 200 back to index.html using the rewrite rule specified here: https://docs.aws.amazon.com/amplify/latest/userguide/redirects.html#redirects-for-single-page-web-apps-spa

Though, it's not clear how that's working, without seeing the underlying Cloudfront configuration. It simply stops executing the 301, which preserves the query parameters.

@hzhenmin what's the solution proposed to allow redirects while preserving query parameters in Amplify?

Were you ever able to resolve this or build a workaround that allowed for query parameters?

[FelixRe0]

+1 Same question here. Using </index.html/> => /404.html [404 Rewrite] #823

[cmaycumber]

I'm running into the exact same issue using the same setup as @FelixRe0 for a Gatsby site.

[bighoot]

I guess I can say it feels better to not be the only one struggling with this.

[bighoot]

Others at my company have recommended trying to build some sort of component that would be able to redirect to where the traffic needs to go (in my case its the callback after logging in to Okta) and somehow preserve the query parameters. But, unless I misunderstand something, there's literally no way to access those parameters in the app, or any app running in Amplify, because as soon as the call hits that boundary, the query parameters are lost. Is that everyone else's understanding as well? Or am I oversimplifying this?

[cmaycumber]

@bighoot We ended up reaching out to AWS technical support so hopefully they can help; I think that passing query params is a pretty vital task.

That's how it should work. The redirects are handled on the CloudFront edge server rather than the client.

[cmaycumber]

We reached out to AWS support and they said that this is currently not supported; referencing this issue.

@bighoot @FelixRe0 One way that we are currently getting around it is passing the UTM's with the trailing slash on the end of the URL with UTMS like https://www.example.com/products/kit/?example=true. AWS console doesn't remove the query params when the trailing slash is included. Not sure if this supports your use case but it seems like it's working for us for the time being.

[bighoot]

I added the trailing / to the end of the redirect URL and to the callback route in the angular app and, like magic, the redirect that took away the params vanished. Thanks! This seems like a complete hack and I have no idea why it works, but it does. Thank you again.

[jlcampos-iies]

Same problem here... stopping an ec2 and starting amplify... everything ok except some issues... one of them refer to authentication from usr/pwd provider during user registration with specific token and tokenId sent by email to the user.... then the user confirm from email through url similar to https://example.com/confirmRegistry?token=value1&tokenId=value2

Adding trailing slash seems not to solve it.

Any new idea???

Thanks in advance

[gwryssekk]

Hi @jlcampos-iies -- Can you give more detail on your use case? What is the expected result when the user tries to confirm via https://example.com/confirmRegistry?token=value1&tokenId=value2 and what is the actual result?

[jlcampos-iies]

Hi @gwryssekk , parameters are used into component to run the provider function that confirms the registry...

params = new URLSearchParams(window.location.search); token = this.params.get('token'); tokenId = this.params.get('tokenId');

ngOnInit(){ confirmUser(this.token, this.tokenId) .then( () => { ... }) .catch( err => console.log(err)); }

The confirmUser function its an http POST request and params are always null because of Amplify redirects to https://example.com/confirmRegistry removing them. So user never can be confirmed.

Regards, Jose Luis Campos

[FelixRe0]

Hi @jlcampos-iies -- Can you give more detail on your use case? What is the expected result when the user tries to confirm via https://example.com/confirmRegistry?token=value1&tokenId=value2 and what is the actual result?

Use https://example.com/confirmRegistry/?token=value1&tokenId=value2 and it will work. Notice the / before the query parameters. Still, the amplify team should make any url work...

[jlcampos-iies]

Hi everyone!

Adding from backend / before the query parameters had desired effect.

Thanks again!

Regards, Jose Luis Campos

[grahamd711]

@hzhenmin has there been any progress in adding support for this feature? This is a critical need for simply redirecting from a naked domain https://example.com to the WWW version --> https://www.example.com

We are not able to preserve any UTM parameters that are crucial to our Jekyll site. Please let me know if there is any type of transparency into the backlog.

Thank you!

[carlcassar]

Can we please have an update on this issue?

I can confirm that @cmaycumber's solution works, but query parameters are an essential feature of web apps. We often don't have control over the code that is calling the uri and can't enforce the addition of a trailing slash.

In my case, I am unable to use Utterances until this issue is resolved since the token is appended to a callback uri that does not add a '/'.

[KLaci]

Any progress with this? It's not okay that I have to update all my links to the ridiculously looking /page/?param=value structure due to the breaking change in Amplify's redirect behavior. I seriously consider migrating to Netlify because of this issue.

[Lasim]

Hi, can someone please provide an update for this issue? I'm using VueJS with nasty workaround for URL parameter.

[santinogue]

Any updates? It is a very necessary feature.

[jimmyn]

I'm also struggling with this. We have moved our website to a new domain and we need to redirect all requests including query params. This is a critical issue for us. Is there any workaround right now?

[Calandri]

Any update?!?!

[Calandri]

Hello, WE NEED THIS feature? Look like AWS is not interest in keepe paying costumer. And AWS it's not cheap. Please. FIX this BUG