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

[DevPowers]

This is happening to me as well, I spent a whole day debugging to figure out the cause and find myself here. Sad to see the issue isn't closed yet after 3+ years

[DevPowers]

Also I haven't seen it mentioned anywhere but if you just use a url with 'www', the query params are preserved.

So trying to navigate to 'example.com/path?query=query1' --results in--> 'example.com/path'

But if you just throw in the 'www' (avoiding the redirect in the first place which strips the params). Such as:

• navigating to 'www.example.com/path?query=query1' --succesfully results in--> 'www.example.com/path?query=query1'

Not a fix at all or even a work around. Just a tip to try and avoid the redirect in the first place.

[simoneagostinelli]

@DevPowers you saved my night!

[dev-sym]

Any hope for this issue to be fixed?

[sadjow]

Believe it or not, the following works:

In the AWS Amplify rewrites section:

• Source address: </^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|woff2|ttf|map|json|webp)$)([^.]+$)/>
• Target address: /
• Type: 200 (Rewrite)

EDIT: this works only for SPA sites.

[dev-sym]

Unfortunately, this doesn't work for me, I am redirecting www to non-www while trying to keep the query string.

[ChoiYongWon]

this solution works for me
the whole rewrite and redirection configuration as below

[
    {
        "source": "/<*>",
        "target": "/index.html",
        "status": "404-200",
        "condition": null
    },
    {
        "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>",
        "target": "/index.html",
        "status": "200",
        "condition": null
    }
]

[smada2108-happly]

this solution works for me the whole rewrite and redirection configuration as below

[
    {
        "source": "/<*>",
        "target": "/index.html",
        "status": "404-200",
        "condition": null
    },
    {
        "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>",
        "target": "/index.html",
        "status": "200",
        "condition": null
    }
]

This is so close to working for me but I lose my custom font when I have this rule :(

[sadjow]

this solution works for me the whole rewrite and redirection configuration as below

[
    {
        "source": "/<*>",
        "target": "/index.html",
        "status": "404-200",
        "condition": null
    },
    {
        "source": "</^[^.]+$|\\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>",
        "target": "/index.html",
        "status": "200",
        "condition": null
    }
]

This is so close to working for me but I lose my custom font when I have this rule :(

You need to include your custom font extension in that list.

[trandaison]

It's 2024 and the issue is still there...
Adding trailing slash is not working.

[swaminator]

@trandaison could you explain what you mean by the trailing slash not working?

[trandaison]

@swaminator Sorry for the confusion.
In my case, the root cause was the cloudfront was not forwarding the query string to the amplify. So adding the traling slash was not working. The problem was not on the amplify itself.

[mauerbac]

Hello everyone -- this issue has been resolved! Now redirects will preserve the query parameter passed to it. Please let me know if you see the correct behavior. @trandaison @dev-sym @iyunusov

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.

[sadjow]

@mauerbac, is it required to declare all the query parameters to it to keep the query parameters in the URL? For example, UTM parameters:

/some-page?utm_content=foo&utm_medium=bar

/some-page/?utm_content=foo&utm_medium=bar

Should we declare variables in all redirects to preserve them, or is this fix still pending deployment?

[mauerbac]

hi @sadjow the team made that change earlier. So a url will go from /some-page -> /some-page/. When doing the redirect it keeps all the query params that was passed to the original request.

[sadjow]

@mauerbac thanks, but for me it still not working. See example: https://www.svenlic.com/contact?foo=bar got removed from the bar after it adds the trailing slash.

[mauerbac]

Do you have any redirect rules? This will work without any the need for redirect rules? I wonder if they could be interfering. What you show should now work without any rules. Let me know what rules are set.

[github-actions]

This issue has been automatically locked.