plugins.file.writeFile

[Harjo]

Hi Alan,

I believe the trick is in turning the JSFile into a RemoteJSFile like so:

I doubt that you need to change a JSFile into a RemoteJSFile, to make this work!
When you are in a webclient, a JSFile is already a 'remote' file.


the wiki says this: https://wiki.servoy.com/display/Serv7/f ... -writeFile

writeFile(file, data, mimeType)
Writes data into a binary file. (Web Enabled: file parameter can be a string 'mypdffile.pdf' to hint the browser what it is, if it is a JSFile instance it will be saved on the server)

maybe there is some NAT stuff going on here, where the server does not know it's public IP, but only it's local address.
I don't how, how Servoy copes with such situation.

[AlanBourke]

It feels like some sort of network issue - unfortunately the code from Robert above presents the same problem - the client browser shows 'connecting' briefly, then nothing happens. No errors, all logging shows as if the file was downloaded OK.

Driving me nuts

[ROCLASI]

Hi Alan,

This also happens when you open the web client ON the server (assuming you have a GUI there)?
Just to rule out the network.

[alan.bourke]

Hi, if I RDP onto the server desktop, it works perfectly via a browser there. It's only when accessed via the internet Tha it doesn't work.

[ROCLASI]

Hi Alan,

So what is the topology of your network ?
Does the server have a real IP ? Is it behind a VPN? Is it behind a proxy (web) server?

[mboegem]

Hi Alan,

I looked up one of my older projects, even logged into their application and did a download.
Works wonderful from a public server + remote client

The code that makes it work:

Code: Select all

function downloadFile(event)
{
   var _rec = foundset.getSelectedRecord();
   var _file = _rec.file_path_relative;
   
   var _jsFile = plugins.file.convertToRemoteJSFile(_file);
   
   plugins.file.writeFile(_rec.file_name, _jsFile.getBytes(), _rec.file_extension);
}


Where the 'file_path_relative' column has stored something like this:

Code: Select all

/2B6B8076-48DD-4B84-99C0-A43585E711CC/myInvoice.xml

This is the relative path to the default upload path of the server
I think this is the area where your issue could be: trying to download an absolute path which doesn't make sense if your on a remote client (browser in this case)

Hope this helps.

[AlanBourke]

Hi Alan,

So what is the topology of your network ?
Does the server have a real IP ? Is it behind a VPN? Is it behind a proxy (web) server?

I will clarify the topology. It's on their LAN yet also has a public IP so I'm sure there's a stack of network between it and the outside world.

[AlanBourke]

Marc

It works fine on a Azure-hosted test server with the same directory structure - I think something in the network setup is causing something in the Servoy stack to go wrong.

[AlanBourke]

Is it feasible to create a Servoy web service that returns a binary object, then leverage that to download the PDF?

This is some sort of Tomcat/network issue as far as I can see and I'm not getting any help from Servoy.

[jcompagner]

what is exactly your setup?
I think you have a tomcat and in front of that you have another firewall/proxy server?

And that proxy server talks to tomcat by tomcats internal ip?

Problem is that when you serve files to the browser we need to make it a full absolute url

what we do then is get the request url of tomcat (so the incoming url) and prepend that in front of the relative url (that points to that pdf)

But if you have a proxy/firewall server in front of this that talks to the tomcat server through its local ip then tomcat gives us that and we prepend the local ip

The thing is that the proxy/firewall should rewrite this. There should be rewrite rules somewhere where it sees certain ip adresses in the responses it should rewrite it to the public one.

the biggest problem here that it is not really a http header or a real redirect

Because this url is in the content, its in an ajax request that looks like this (you can see this in the chrome network inspector)

Code: Select all

<?xml version="1.0" encoding="UTF-8"?><ajax-response><evaluate><![CDATA[Servoy.HTMLEdit.removeInvalidEditors();]]></evaluate><evaluate><![CDATA[storeValueAndCursorBeforeUpdate();]]></evaluate><evaluate><![CDATA[setValidationFailed(null);]]></evaluate><evaluate><![CDATA[restoreValueAndCursorAfterUpdate();]]></evaluate><evaluate><![CDATA[setStatusText('Ready');]]></evaluate><evaluate><![CDATA[showurl('http://localhost:8080/servoy-webclient/resources/servoy/resources',0,false,true,false);]]></evaluate><evaluate><![CDATA[clearDoubleClickId('id5')]]></evaluate></ajax-response>


there you see that "showurl" that has in my example localhost:8080

So currently you have to have some rewrite rull that rewrites that too the public ip...

We could if needed do this rewrite maybe in servoy, where you then say in a property on the admin page what the public ip should be.
Or maybe this is also set in the headers somehow where we could potentally extract it (not sure if that is always the case)

[AlanBourke]

Johan

Sorry only just saw your reply.

The topology is possibly slightly unusual in that it is a Windows Server 2008 server that is hosting Servoy. It has a publicly visible IP address which end users hit, however it also is on the client's LAN with a private IP. So WriteFile() seems to be favouring the private IP when building the URL for the browser, and there is no mechanism for overriding this within the Servoy stack.

Providing an Servoy admin page setting to provide the public IP would be great, do I have to file that as a request?

[jcompagner]

Make a case for this yes.

[AlanBourke]

Okay, it turns out that the server is behind a product called Sophos UTM Web Server Protection. This has a per-server 'pass host header' setting which was disabled but when enabled appears to have solved thr problem, and WriteFile() acts as expected in this scenario.

When it's not permissions, it's always a bloody firewall or something.