For a variety of reasons, I need programatic JavaScript access the the hostname or IP address of the Worklight server from the client code.
For example:
- I want to pull scripts and resources from the same host as the Worklight server
- I have an out-of-band service on the Worklight host and I want to connect to it
#IdanAdar has said that the address does not exist. I've search the WL object and cannot find it either. See Can we get the app version and IP address info using worklight api?.
Note that document.location.hostname is null when running as a native app.
My current workaround is to set the IP Address / hostname as a global variable in my top-level html file. This is not ideal because it causes my sourcecode to have to vary by implementation.
Worklight already has this value externalized in the application-descriptor.xml
The server side API has this exposed in WL.Server.configuration["local.IPAddress"]. I think the client should expose an API similar to this as well.
Although not the best option you can develop an adapter that returns the WL.Server.configuration["local.IPAddress"] if available, also could be possible to acces to the IP through the http request.
Is it possible to access to the HTTPRequest in the worklight adapter implementation?
I'm not sure if you can invoke adapters before wlCommonInit, if you can not and you need the ip before the common init then this approach is useless.
Related
I am using IBM MobileFirst Platform Foundation 8.0.0. I have a Java Adapter that is deployed on the mobilefirst server that is calling an external service. After creating a resource on the external system, I return the created id on “location” response header. It gives me the complete url of the created resource of the external system like http://example.com:1234/resource_name/1234
I don’t want to expose the external system’s url to the caller / client of my adapter. I want to return something like this - http://mobilefirstserver.com:6789/mfp/api/adapters/MyAdapter/resource_name/1234
where "mobilefirstserver" is the server on which MyAdapter is running. I am unable to find any method from mfp libraries where it can retrieve “mobilefirstserver” and “6789”. I can retrieve the adapter’s target URI, which is “example” and “1234” from adapter.xml, but not the host and port details of the mobilefirst server.
Some options:
Use the configuration API to obtain it: ConfigurationAPI.getServerJNDIProperty("mfpadmin/mfp.admin.authorization.server.url") - this will be something like this: http://localhost:9080/mfp/api. You will need to extract the host and port from it.
You could use, on the client-side, the WL.App.getServerUrl API and use it as a parameter in your call to the adapter. But that little sense for your scenario (although I didn't fully 'get' what is the scenario).
Since the server is yours, you can simply hard-code these values in your adapter implementation.
I have implemented a Push Notification adpater and would like backend system to call the procedure in order to submit notification.
With reference to this post, http://server:port/dev/invoke?adapter=adapterName&procedure=procedureName¶meters=1,2,3 can be used but it works in development environment only.
At the end of the post it is mentioned that http://server:port/context/invoke?adapter=adapterName&procedure=procedureName¶meters=1,2,3 can be used to invoke the adapter.
(1) May I know whether it is supported in production environment only? Because it returned HTTP method GET is not supported by this URL in development environment.
(2) Noted that we might need to define securityTest="wl_unprotected" for the adapter and thus the adapter is not protected. What will be the best way to achieve the goal for backend sytem to call the adapter with security control?
In Worklight 5, Worklight Studio uses Jetty within and the usage of a context root is not required. Only once moving your project to an application server such as Tomcat, WebSphere, Liberty, you have to specify it (in worklight.properties and application-descriptor.xml).
So,
in development - no.
in production - yes.
In Worklight 6 where Jetty has been replaced with Liberty, context root is now part of your project whether you are in development or production.
You will have to add the "wl_unprotected" securityTest to your procedure in the adapter XML.
As for protecting the requests, my guess is that your IT department can isolate and protect specific URLs and not allow using them in certain scenarios. You already have the URL structure for them to use.
I have seen some questions about dynamic adapter configuration at run-time
how to pass domain,port number,username and password from user input to worklight http adapter
With a Worklight Adapter can I change the domain and port for a procedure at runtime?
but my question is about adapter configuration after deploy on WL server 5.0.6 from external - not at runtime from code.
Our scenario is that in our enterprise development and testing process requires the QA and Testing team to change the destination host and port for the adapters from mockup-backend to testing-backend to production-backend regularly during testing.
of course, this should happen through configuration and not re-compile and re-deploy.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6?
Can this be changed in the WL database tables?
Can this be changed in the WL server filesystem somewhere?
since we did not find any solution to that yet, the developer team is already thinking about using the Adapter only as dumb facade and implement all connection to the backend-services in Adapter-side Java using the Java URL and Connection classes.
Then it would be easy to read a configuration file from the file system in Java to change the backend destination URL and ports in this file.
It would even be easy to read the URL and port from a property in the worklight.properties file in JavaScript and pass it to Java to connect.
I would like to avoid having developing all backend connection code in Java. I would rather see the project use the actual Adapter connectivity features, but I am also not sure how to convince the team since it is quite easy with just 4 lines of code in Java. The advantage of using the Adapter connectivity that can not be configured is hard to see over a own Java implementation in Adapter-Java code.
Thank you.
Is there a way to change the domain and port values for adapters that are deployed on the WL server 5.0.6? Can this be changed in the WL database tables? Can this be changed in the WL server filesystem somewhere?
In Worklight 5.0.6, as written in the questions you've linked to in the question, an adapter's connectivity settings cannot be altered. They are stored in the packaged adapter and cannot be read from anywhere else during runtime nor after deployment.
Not sure if i'm really up-to-date, but i'm looking in a way to convert my existing project to use HTML5 websockets.
Here's my situation :
- Client runs a modified java vnc applet with extra parameter (CONNECT).
- Modified stunnel listenin on webserver (with both public, private IP) port 443
- Client connects to 443 and sends (prior to RFB) a HTTP packet like :
'CONNECT 10.0.0.1:4001'
- Stunnel opens a new stream to 10.0.0.1:4001 using SSL wrapper
- VNC Server (#10.0.0.1:4001) responds, connection is established.
Now I want to get rid of the Java Applet and switch to Websocket using NoVNC.
I want to be able to :
- Open a single port on the webserver (HTTPS preferably)
- Have client connect using HTML5 only (no more java applet)
I cannot change :
- VNCServer will still be listening on private LAN only.
- VNCServer will still listen to a bunch of ports, each corresponding to
a virtual server
Questions are :
- How to give NoVNC the notion of target HOST:PORT ?
- Is stunnel still be usable ? Or should I change to websocket proxy ?
If anyone has a starting point, i'd really appreciate !
Disclaimer: I created noVNC so my answer may be heavily biased ;-)
I'll answer you second question first:
stunnel cannot be used directly by noVNC. The issue is that the WebSockets protocol has an HTTP-like initial handshake and the messages are framed. In addition, until binary payload support is added to WebSockets, the payload is base64 encoded by the websockets proxy (websockify). Adding the necessary support to stunnel would be non-trivial but certainly doable. In fact noVNC issue #37 is an aspirational feature to add this support to stunnel.
First question:
noVNC already has a concept of HOST:PORT via the RFB.connect(host, port, password) method. The file vnc_auto.html at the top level shows how to get noVNC to automatically connect on page load based on the host, port and password specified as URL query string parameters.
However, I think what you are really asking is how do you get noVNC to connect to alternate VNC server ports on the backend. This problem is not directly addressed by noVNC and websockify. There are several ways to solve this and it usually involves an out-of-band setup/authorization mechanism so that the proxy can't be used to launch attacks by arbitrary hosts. For example, at my company we have a web based management framework that integrates noVNC and when the user wants to connect to the console, an authenticated AJAX call is used to configure the proxy for that particular user and the system they want to connect to. Our web management interface is internal only.
Ganeti Web Manager uses a similar model and the source is available. They have a fork of VNCAuthProxy that has WebSockets support. They use a control channel from the web interface to the VNCAuthProxy to setup a temporary password associated with a specific VNC server host:port.
Also OpenStack (Nova) integrates noVNC uses a similar out-of-band token based model to allow access with their nova-vncproxy.
Some links:
Ganeti Web Manager
Wiki page about how noVNC works in Ganeti Web Manager
Ganeti Web Manager sources
Ganeti Web Manager VNCAUthProxy sources
Using noVNC in Nova/OpenStack
OpenStack fork of noVNC
Old nova-vnc-proxy code
Current nova vnc proxy code
This is probably a basic networking issue, but I am new to this stuff and just do not know the answer.
I have written a wcf service and client. I can use one of the http bindings and get the service to work correctly when I put my machine's network IP address as the endpoint address and run the client and server from the same machine. Now, I want to be able to connect to this service from a different machine over the internet. Clearly it does not work when I use my network IP address in this scenario, but simply putting in my router's broadband IP address does not seem to be doing the trick, either. Am I just missing a firewall port that I need to open up, or am I trying to do something that should not be possible?
If you want users from the internet to be able to connect to your service, you'll have to consider a few points:
binding: the lowest common denominator is the basicHttpBinding which is SOAP 1.1 with basically no additional features available - just like ASMX webservices. Just about anyone can connect to that. For more advanced clients, you might also want to expose a wsHttpBinding endpoint on your service
security: how (if at all) do you want to secure access to your web service? Do you have username/password credentials that callers must supply? Check out the WCF Security Guidance for a whole slew of information bits on the various security scenarios
authenticating your service: typically, you should strive to make your service authenticate itself to the rest of the world - this requires a server certificate and enables secured communication (messages signed + encrypted) on the wire
make sure your service endpoint(s) is reachable from the internet, through all firewalls and proxies and everything :-)
Hope that helps a bit!
You need to set up port forwarding on your router. Perhaps someone on ServerFault or SuperUser would be able to help you. Or even a google search now that you know what it's called. The instructions will be different depending on the router. The port you need to forward will be the port you've picked in the WCF config file.
I host WCF services through IIS, but it took me ages to work out how. At the moment I put the files on the webserver and enable websharing on the root folder. Then you can assign them to an appropriate Application Pool in IIS, and add a service reference to any client projects using the URL of the wsdl.
I'm not sure if this is the best way to do it but its the only way I've worked out so far.
Here's the simple solution.
I am assuming that you have made a working WCF application and hosted over the IIS.
The next thing to do is to browse the application from the IIS. It will give you url in the address bar something like:
http://localhost/myservice/service.svc
Next go to www.whatismyip.com. this will give you your system's WAN IP (say, 45.34.56.200).
Replace the URL you got in step 2 with: http://45.34.56.200/myservice/service.svc
Now you can use this URL any where in this world to consume your service.
I found a good Article and it is working fine for me, on the following the Main steps:
1-First you should create WCF Service.
2-add application on IIS and give alias for your virtual directory and set path from your local drive.
3-Make sure your default app pool set to .NET CLR V4.0.
4-test your WCF service is running successfully on localhost.
5-To access the same via LAN (Local Area Network) you must disable Firewall for you Private network.
6- try to use ngrok.com, you will get Temp URL to use via internet to access your LocalHost anywhere.
Then Everything will be fine.
For More Information Check the following Link:
https://www.codeproject.com/Tips/813650/Host-WCF-on-LocalHost-and-access-via-Internet