Layer7 - reverse proxy with react.js portal

[Alfredo Cosco]

Hello,
I'm working with Layer7 on a reverse proxy policy, I have to reverse of a portal made with REACT.

I'm able to reverse almost everything but I'm facing an error that I can't understand.

The reverse proxy breaks on a call on a relative path, the call is related to a REACT module and is dinamically generated by a javascript [i.e. it is not hard coded anywhere] , and I'm unable to overwrite it as usual using a regex assertion. (see the attached screenshot)

Did someone faced a similar case?

Thanks,
Alfredo

[Barry Stern]

Hello Alfredo,

The image is to small to see anything. Cna you post a bigger image and details regarding the issue you are having.

[Alfredo Cosco]

Hello,
thanks for your reply, today I discovered that the problem is not react.js but the Laravel framework that works as backend for the react app. 
The problem is this:

The L7 url is:

www.mydomain.com/foo/bar/sessionName/sessionID

The url of the app that L7 reverses is:

www.appdomain.com/sessionName/sessionID

The laravel framework uses the request url path segments for variables values as alternative to a classic query string. 

So, the application takes the value in position 2 (i.e. sessionID) to launch a query against the DB.

But in the L7 path the position 2 has value "bar" and the sessionID is in position 4, and the query fail. It is strange because anything seems correclty reversed and I don't think that a server side framework as Laravel takes the variables from the browser url address.

Did someone face a similar problem? 

Regards,
Alfredo

[Jay MacDonald]

Hi Alfredo,

  As Barry mentioned, the image is too small to understand. Can you please be more explicit about your use case? Can you share the policy in the API Gateway?

  When you say "The L7 url is: www.mydomain.com/foo/bar/sessionName/sessionID", is that the url at the front of the API Gateway? I.e. how it is called at the Gateway which then rewrites the backend route to "www.appdomain.com/sessionName/sessionID"? It is unclear to me what you are trying to do here.

Thanks!

JayMac

[Alfredo Cosco]

Hello,
I try to explain the problem:

1) the policy: a common reverse proxy policy made by the layer7 wizard

2) the layer7 url exposed on internet: www.mydomain.com

3) the application url to reverse (not exposed in internet): app.mydomain.com

4) The path under L7 where I made the reverse proxy: /foo/bar

So the public URL:
www.mydomain.com//foo/bar/sessionName/sessionID

relays to:

app.mydomain.com/sessionName/sessionID

The problem: the application searches in the path segment number 2 to get the "sessionID" but it finds the word "bar" 

I thinkl I'm doing something wrong in the reverse proxy, but I just followed the wizard.

Thanks,
Alfredo

[Barry Stern]

Hello Alfredo,

This is done in policy by
1 - set context variable path to ${request.url.path}
2- add regex to remove /foo/bar from path defined in step 1.
3- modify routing assertion to reference ${path} instead, which will now contain the request path with out the /foo/bar.

[Jay MacDonald]

Yeah, the wizard is a bit brain dead in this regard, IMO. The assumption is that the path part of the URL will be the same at the Gateway as at the back end service. Per Barry's answer, you need to rewrite the path to remove the extraneous elements and use the new variable in the routing assertion. Copy and paste the following XML into your policy. It introduces to new assertions to assign ${path} and regex it to remove ^/foo/bar, then shows it being used in a replacement routing assertion:

<?xml version="1.0" encoding="UTF-8"?>
<wsp:Policy xmlns:L7p="http://www.layer7tech.com/ws/policy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2002/12/policy">
    <wsp:All wsp:Usage="Required">
        <L7p:SetVariable>
            <L7p:Base64Expression stringValue="JHtyZXF1ZXN0LnVybC5wYXRofQ=="/>
            <L7p:VariableToSet stringValue="path"/>
        </L7p:SetVariable>
        <L7p:Regex>
            <L7p:AutoTarget booleanValue="false"/>
            <L7p:OtherTargetMessageVariable stringValue="path"/>
            <L7p:Regex stringValue="^/foo/bar"/>
            <L7p:Replace booleanValue="true"/>
            <L7p:Replacement stringValue=""/>
            <L7p:Target target="OTHER"/>
        </L7p:Regex>
        <L7p:HttpRoutingAssertion>
            <L7p:FailOnErrorStatus booleanValue="false"/>
            <L7p:ProtectedServiceUrl stringValue="http://${webAppHost}${path}${query}"/>
            <L7p:ProxyPassword stringValueNull="null"/>
            <L7p:ProxyUsername stringValueNull="null"/>
            <L7p:RequestHeaderRules httpPassthroughRuleSet="included">
                <L7p:ForwardAll booleanValue="true"/>
                <L7p:Rules httpPassthroughRules="included"/>
            </L7p:RequestHeaderRules>
            <L7p:RequestParamRules httpPassthroughRuleSet="included">
                <L7p:ForwardAll booleanValue="true"/>
                <L7p:Rules httpPassthroughRules="included"/>
            </L7p:RequestParamRules>
            <L7p:ResponseHeaderRules httpPassthroughRuleSet="included">
                <L7p:ForwardAll booleanValue="true"/>
                <L7p:Rules httpPassthroughRules="included"/>
            </L7p:ResponseHeaderRules>
        </L7p:HttpRoutingAssertion>
    </wsp:All>
</wsp:Policy>
​

[Jay MacDonald]

Note that if there are any url components in the response, like a location header or in the body, that will need to be rewritten as well so the client gets the Gateway's version of the url and not the back end's.