How should I get redirect url for a given url in code?

[jaandrews]

I'm using urltracker in a headless environment, so the url requests are coming through via an api call, rather than from the umbraco front end. I've looked at the source code, but haven't been able to figure out how it matches the requested url to a redirect (if any). I found UrlTrackerRedirectMiddleware, but I haven't been able to reach a solution based on the code there. I could brute force this by getting all of the redirects using the redirect service, but since this api will be called on each page visit, I would like to get it the same way UrlTracker does for normal front end requests to optimize performance.

Any ideas on how I should do this?

[D-Inventor]

Hi @jaandrews !! That's an excellent question and I should be able to help you with that. To find a redirect in custom code, you need to inject the IInterceptService from the UrlTracker.Core namespace into your own code. This method requires a parameter of type Url. You can either use the constructor on that type to build your url, or you can use the static Parse method to parse a string into an object.

Keep in mind that an intercept is an intentionally vague model as an intercept might not always be a redirect. You will have to map this intercept model to a viewmodel if you want to pass it to the frontend.

I hope that is enough to get you going, let me know if you have any questions about this or if you run into any issues.

[jaandrews]

@D-Inventor Thanks for the input. I was able to figure out the problem. I was using the intercept service you suggested, but wasn't getting the expected redirect response. Turns out the problem was that the redirect was entered as a relative url, and it needed to be an absolute url since umbraco had a full domain set for its hostname. Below is my code for anyone else that tries to implement this.

public async Task<Models.Redirect> GetRedirect(string url) {
    var uri = new Uri(url);
    var requestUrl = Url.Create(Protocol.Https, uri.Host, uri.Host != "localhost" ? null : uri.Port, uri.AbsolutePath, uri.Query);
    if (await _requestFilters.EvaluateCandidateAsync(requestUrl)) {
        var response = await _interceptService.GetAsync(requestUrl);
        if (response == null) {
            return null;
        }
        if (response.Info is UrlTracker.Core.Models.Redirect) {
            var redirect = (UrlTracker.Core.Models.Redirect)response.Info;
            var destination = redirect.TargetNode != null ? redirect.TargetNode.Url(redirect.Culture) : redirect.TargetUrl;
            if (redirect.RetainQuery) {
                destination += uri.Query;
            }
            return new Models.Redirect {
                Destination = destination,
                Permanent = redirect.TargetStatusCode == System.Net.HttpStatusCode.MovedPermanently,
                Host = uri.Host + (uri.Host == "localhost" ? ":" + uri.Port : "")
            };
        }
    }
    return null;
}

The returned object can be whatever the project needs. IInterceptService interceptService and IRequestInterceptFilterCollection requestFilters will need to be added with dependency inject for this code to run. Note that this is for v10 of UrlTracker, so there may be differences when running a different version.

[jaandrews]

@D-Inventor Just so you are aware, I did run into some weirdness with this functionality. When running locally, the redirect fired properly when the source url was relative ("/test/") or absolute ("https://localhost:12345/test/"). However, when I deployed it to azure, only the relative path worked for some reason now. The absolute url ("https://www.example.com/test/") fails to match a redirect. I copy/pasted the source url from the front end multiple times, so I know it's not a typo. You can see a few test cases I made in the below screenshot (site isn't actually pointed at www.example.com; I just used it as a placeholder to avoid exposing the url of the under development site).

Any idea why this might be happening?

[D-Inventor]

There could be several explanations for why it might not match on the absolute url.

Most likely, you're hosting behind some form of proxy (cdn, azure frontdoor, etc.) and the incoming url on your application is not the same as the url you enter in your browser.

Usually for cases like this, you need to use the Forwarded Headers middleware.

Does that seem plausible?

[jaandrews]

@D-Inventor I'll look into that. I know the front end server is running behind a proxy, but I'm not certain the umbraco environment is. Its hostname points at the front end domain though, rather than itself, so might still be affected by that even if the umbraco environment isn't behind a proxy.

[jaandrews]

@D-Inventor Found the problem. After putting url tracker in debug mode, I noticed that ":443" was being appended to the domain, since I set a port number when creating the requestUrl object. This worked locally since the port was part of the url, but that isn't the case for the azure domain. The port just needed to be null for it to work correctly there. I've updated the code above to check for this.