Calling webservices by IP address

[SpringBox]

Hi guys

Came across an issue calling webservices in code. Some we call using their fully qualified domain and some we only have an IP address.

In dev / app cente and localhost web on dev pc - works great and very fast but in cloud server, always just times out with no connection to the external service.

Is this some sort of sandboxing issue or should we be able to call webservices by IP?

i.e.

oRequest = createObject("networkrequest")
lretval = oRequest.postfile("http://222.222.222.222/webservices/webservicename.wx", "dataexport.json", "result.txt")

This one is driving us nuts !!

Edit :
Now created a subdomain and assigned it to static IP - again works perfectly in Dev, App Centre and localhost web on dev pc but not when called on Cloud Server. Other webservices call fine.

Only option is to raise a ticket now.


Thanks in advance


Simon

[barrymavin]

Hi Simon,

No there’s no sand boxing as you put it.

Have you tried this interactively in the app builder console? I mean have you tried with numeric ip addresses.

This is likely to be a reverse DNS issue.

You can use tracert in a command window and that may help you to see what’s going on.
https://support.microsoft.com/en-us/...ems-in-windows

and nslookup

https://serverfault.com/questions/41...se-dns-look-up

[SpringBox]

Hi Barry

Yes - this one is odd and thanks for confirming that there is no sandboxing in the Cloud Server. It must therefore be a routing issue somewhere.

In console and in code it works perfectly (both as IP and domain endpoints) but for some reason, not on the production server where there is only Cloud Server.

Both tracert and ping show no issues so we have now put our server farm tech people on it to look for some weird http security. (it is bound to be some firewall setting somewhere)

Thanks for your swift reply

Cheers

Simon

[HankFay]

Hi Simon,

Is the LCS on the same server as the app development? It's not unusual for ftp requests to be accepted only from specified addresses. It's also not unusual for an FTP server to automatically created a blacklist for IP Addresses that fail authentication <n> times, with various variations on the principle.

When I put an ftp server on a rented box I immediately limit IP addresses from which requests can be accepted. Failing to do that will, within hours if not minutes, lead to a plethora of attempts to get into the system, from many different countries.

Hank

[SpringBox]

Hi guys

We found our issue - it was some routing rule because we were calling a webservice on our own subnet and apparently that is not supported on some virtual server platforms. We are now calling internal ip address which works fine.

However, now we've got it all working and are testing, we have come accross a really weird one...

We can log in to our web app on production server using port 8001 or port 80 on server using wifi or wired network :

Internet Exlorer on pc
Firefox on pc
Chrome on pc
Flashpeak slimjet on pc

Android tablet as web app
Android phone as web app

But we cannot log in using any apple devices.

Safari iPad ios 13.1.3 or iPhone ios 12.4.1 - the connction counter increments on the Lianja Server Manager, we enter the password on the app center login, the password is accepted and then nothing happens and we never get to choose our app. Spinner just keeps going and nothing happens. This is true for wifi or cellular and for both port 8001 and port 80.

Safari and Aloha browsers tried on iphone - same fail result.

We have now tested this on 4 different ipads from 4 different LANs and always the same.

This used to work but has apple introduced some manditory requirement for https? If so, how would we do that with Lianja Server Manager? Can it listen for SSL port 443 too? How do we install certificates?


mac - not yet tested

Unfortunately our customers all use Apple !! Any thoughts? URGENT....

Thanks in advance



Simon

[HankFay]

Hi Simon,

We use HTTPS for all our web client work, using IIS (there's a page, actually 2, on that -- Google 'Lianja IIS'). Performance is good.

You can also use Apache as the frontend.

HTTPS for the LCS is on the roadmap somewhere.

Hank

[barrymavin]

Use the web inspector on iOS from your desktop.

https://appletoolbox.com/use-web-ins...mobile-safari/

Or debug using chrome on a Mac connected to your iPad

https://blog.chromium.org/2019/03/de...e-for-ios.html

[SpringBox]

Hi Barry

Sadly we use PCs and don't have any Macs. Do you think this might be something other than https? We are only trying to make a very simple web app.

We have installed the Lianja64.dll in to IIS which installed perfectly (great instructions, thank you)

We then installed the https binding and of course IIS is now completely trashed with no localhost. It always does that whenever you touch it. So unstable.

Anyway, back to Lianja.

We are slightly confused as given that Lianja Cloud Server listens on port 8001 and SSL is 443 and we have integrated calling our app with IIS, how do we now call it?

https://222.222.222.222:8001/login.rsp looks wrong with https://222.222.222.222/login.rsp looking better. We will try this on a self signed certificate to being with before we buy one.

We have tested this fairly extensively and it now works so well with everything other than ios.

Do we really have to go and buy a (absurdly expensive) Mac just to get it to load? It used to work. Anything else it could be? Is there some app setting that might be an issue?

Cheers

Simon

[HankFay]

Hi Simon,

You can set IIS up to use both 80 without SSL and 443 with SSL.

LCS on port 443 is not SSL: it is just port 443. Without binding an SSL certificate, there is no HTTPS.

Hank

[SpringBox]

Hi Hank

Yes, we understand that & it makes sense. We now have IIS set up for http 80 AND https/SSL 443. Its just that now nothing comes through but we hope to fix that.

But how would we call an https/SSL version of our app from a browser? Would we need to specify a port? How do we get LCS to be listening on 443?

This is the last bit of the puzzle, we hope....

It's been like climbing Everest to get a coffee.

Thanks

Simon