What does the FME_SERVER_WEB_URL FME Flow Parameter Actually Do?

Hi ​@ivanwriter,

FME_SERVER_WEB_URL is the base URL of your FME Flow Web Application Server. It is used by some FME processes that need to pull in the server URL. For example, in FME Form, you can set this parameter for local testing. When the workspace runs on FME Flow, the value is supplied automatically from fmeFlowConfig.txt. 

The FME_SERVER_WEB_URL also exists in the fmeFlowWebApplicationConfig.txt file. This value is used for sending Data Virtualization requests within the Data Virtualization Swagger Documentation. 

You should be able to set it to the external FQDN you expose. If you need a server to reach Flow internally while keeping the external FQDN, you can add a hosts‐file mapping on that server so the FQDN resolves to an internal IP.

Thank you, ​@dylan.at.safe for the info. I changed the FME_SERVER_WEB_URL parameter in my fmeFlowConfig.txt to the server name (proxy server) I want to show. That did improve some of the info coming back from a badly formed web-hook request--as it shows the server name I want to show.

However, doing this didn’t clear up other info returned from a badly-formed web-hook request--info that I would prefer to not show up.

A badly-formed web-hook request (using a parameter name that doesn’t exist) still returns:

• FME_SERVER_REQUEST_HEADERS:  This shows the internal IP (not the external IP) of the proxy server (which I presume would be the web-hook requester). It also shows the hostname and port number of the internal server.
• FME_SERVER_REQUEST_URI:  This shows the hostname and port of the internal server.

Is there a way to prevent this info from being returned? I tried setting FME_SERVER_REQUEST_HEADERS and FME_SERVER_REQUEST_URI to blank in a workspace, publishing that workspace as a web hook, and sending a badly formed request. That did nothing, which makes sense, given that these parameters seem to be dynamically set according to what machine is requesting the workspace and what machine is running the workspace. But, again, such info isn’t necessary for external users.

Also, FME_SECURITY_USER and FME_SERVER_RUNTIME_USER (both set to publisher of the workspace) are in the error message and are too much info--info that ideally doesn’t go out. FME_SERVER_PORT (port on which workspace is invoked) isn’t needed either.

Hi ​@ivanwriter, 

Could you open a support case with us using the following link: https://support.safe.com/hc/en-us/p/Support? I’d like to see a screenshot of the behavior you’re observing and, if possible, the workspace being used. It sounds like this may be unexpected behavior, and it would be helpful for us to reproduce it on our side to confirm whether it’s unintentional. Please link this community post in your case. 

Sure, ​@dylan.at.safe . Thank you.