I'm having a strange problem. I have a Java application which I want to run using Java web start. This Java application is signed by a trusted authority (digicert) certificate. When I deploy my application to my local glass fish 4.1 server and run the Java I get the dialogue "do you want to trust ....). So far so good. When I deploy the exact same app to a glass fish server hosted on a remote machine (Amazon instance) and attempt to run the Java web start app, I get. "This application is blocked" message, as if the Java app is not signed. What is the cause of this behavior? My remote server uses ssl connections, but even when I specify http in the jnlp I get the same problem (my server listens to both http and https). This has been driving me crazy for three days now. Please help.
There are other hoops to jump through. You need a permissions applet
tag, and the main jar has to have a matching permissions line, and
a codebase line compatible with the site being loaded from.
All the jars have to be listed in the jnlp.
Related
I know that, Oracle MAF is used to develop hybrid mobile application for both Android and IOS device with native look and feel.
I have created REST Web Service and deployed on the WebLogic server as described in this tutorial and also created mobile client app for Android device with use of Android SDK. It is running successfully on Android Device.
Now, It is possible to run mobile client on server (May be WebLogic, Glassfish, Tomcat) so that it can be accessed as a Web Version (Web Application).
As a try, I have zipped mobile client application as a war file and also deployed on Tomcat and WebLogic but without success.
Below is the error message which I got when accessing the home URL from WebLogic server.
Error 403--Forbidden
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
Share yours ideas to resolve this issue if you have any, it will help current and future MAF developers.
MAF creates application that deploy and run on the device.
ADF creates server side applications that can be accessed from the browser on a mobile device.
Two separate architectures addressing two separate needs.
No it's not possible. Zipping the .apk (Android) or .ipa (iOS) file will not make it a web application. Those files are also containers but they contain native code.
Use Oracle ADF for web applications.
I have a web application that uses a Java applet to get my clients' system information by executing vbs code in Windows or basic commands in Linux, and network address too with java.net.InetAddress in order to log them into the webapp through ldap.
Due to Java applets will not be supported anymore shortly in the majority of browsers, I'm looking for another way of getting this information. Is there any way of doing it?
Thanks,
xavi
EDIT: Required information: System (OS, RAM, HD, IP, MAC) and network (username, machine name, domain name)
All you basically need is some sort of module that can be downloaded from you application over the network, which would run locally on client machine and would do stuff you require.
Since Applets seems to a little outdated, there are other options as well.
You can use JNLP, it would work just like applets, but the whole package would be downloaded first and would require JRE on client machine to run it.
So I just got internship at this company, and they would like me to complete a project(Web application) which someone else did but didn't finish two years ago. But the person didn't leave any documentation about this web app. Right now I would like to run and test this web app, but I couldn't get it started.
So it's running on WebSphere Application Server in IBM Rational Application Developer, the code is written in java and javascript. (I could start the server, but I don't know where to go and open up the web app)
Sorry I'm really new to this, questions might be stupid, appreciate any help:)
Do you know what port it's running on? You should be able to access it from a web browser on the host machine by going to
http://127.0.0.1:XX
where XX is the port in question. If you don't know, try 80 - that's the default HTTP port and it's worth a shot.
The default websphere web port is 9080, so try http://localhost:9080/
So it's running on WebSphere Application Server in IBM Rational Application Developer
and
I could start the server
Assuming you are able to start the server via RAD as I assume from the above and you are able to publish the app to WebSphere via RAD, you should then be able to right click on the project folder and choose "Run on Server." It will walk you through publishing the app to the server and will then launch a browser to the index page or URL via the context path and web project settings. You can have RAD use an embedded browser (default) or adjust it to launch an external browser via Preferences -> Web Browser.
To manually check where a webapp will be deployed you can either check application.xml (if you have one) OR you can right click on the project root folder in RAD, choose Properties, and Web Project Settings. The context path is in a field there.
Run-On-Server will show you both server/hostname (usually localhost), port, and application context path in one operation.
I have a web application running with support for some specific pieces of hardware. This is achieved in the following steps:
User runs a small installer that places java files (and a couple
others) on the client machine. The main piece is a jar called "hardwareManager"
User visits web app. The web app runs a java applet which, due to
a .java.policy file placed during the install, has permission to
interact with the client machine outside the browser sandbox.
The applet checks to make sure the hardwareManager is running,
and if not runs a command to start it.
User interacts with the web app which sends commands to the applet via
javascript. The applet then writes commands to a text file
on the client machine. The text file is constantly monitored by the
hardwareManager which runs any commands it reads in.
This works, but seems clunky. I have a couple ideas on how to improve it, but I don't know which, if any, are even worth trying.
Would it be better to set up the hardwareManager as a socketServer and have the applet connect directly to it, rather than going through text files? Is that even possible?
Is there a way to eliminate the applet altogether and have the javascript talk directly to the hardwareManager? Maybe by writing the hardwareManager to be a local http server? What port should it run on? Do javascript xss limitations fit in here somewhere?
It would be less clunky to start the Java application using Java Web Start. This would remove the need to daemonize or install the Java hardware manager.
Another alternative is to use a built-in browser inside Java. I supose this is not an option, since you depend heavily on Javascript (I suppose to provide a rich client experience).
If you already have to install something on the client machine, why did you make the choice to go with a web application?
Talking from experience: We had a Java EE application which needed to print to PoS printers at the client site. We installed a small "synchronizer" application that connects through SSH and synchronizes all clients files. Afterwards, it loads the JAR and executes the program. This program connects through RMI with the server and subscribes to a JMS queue to receive the print assignments.
Applied to your case: Why not let your Java application connect to the server directly? You can use HTTP, SOAP or even JMS over RMI. You can then launch the hardware command from the server (instead of from the limited JavaScript webbrowser environment). This way, you get tons of features: authentication, buffering of commands, and you can even share hardware between multiple clients.
Schematic:
<----AJAX------> Web browser
ApplicationServer
<---HTTP/SOAP--> Java hardware manager application
You can launch the Java application using Java Web Start, which allows you to update the application automatically (instead of needing to pass every client a new installer).
I have never used JNLP, and I have no web/war server already running so I will install it from sratch:
Which to use?
GlassFish
Tomcat
Apache
Jetty
Another?
I wonder if someone already using JNLP could make any recomendation for the server.
I just want a blank page with a button in the middle for starting the application nothing more, nothing less.
If you use only JNLP you don't need Java server. JNLP is client side. Simple http server like Apache HTTP Server should be OK. HTTP server will be better solution than use of web container/Java EE server because JNLP (usually) is a static content. Even lighthttpd should be enough.
As already stated any server capable to serve HTTP will do. If your WebStart application is not signed by itself (i.e. you code-signed the corresponding Jar files) you could probably consider to publish the JNLP plus its resources via HTTPS. This way your clients will know that the software they are going to execute came from its rightful origin. Although unsigned WebStart applications are restricted in their privileges on the client's machine it still is a measure to elicit trust in your clients. On the other hand this requires more configuration effort with regard to the server you chose.
If your application will need some extended privileges on the client's machine such as access to the file system then I would recommend that you do sign your jar files to gain the necessary privileges automatically (don't forget to specify them in a element within your JNLP).
These are the default restrictions for unsigned WebStart apps:
No access to local disk.
All your jars must be downloaded from the same host. Note, however, that you can download extensions and JREs from any host as long as they are signed and trusted.
Network connections are allowed only to host from which your jars were downloaded. ("Phone home restriction.")
No security manager can be installed.
No native libraries (not even in extensions).
Limited access to system properties. (The application has read/write access to all system properties defined in the jnlp file, as well as read-only access to the same set of properties as applets
You dont need a server to run JNLP(Webstart).. This is how webstart works
it simply is an application that can be started over the web, this would be the procedure from the user perspective:
user goes to yourwebsite.com
user see's link: run my awesome app
user clicks link, which downloads .jnlp file
user runs the jnlp file through java web start (part of java SE, user requires java runtime environment JRE to run this)
java web start reads jnlp to get information about the server that holds the corresponding application
jar files get downloaded automatically (the first time) and then the application starts
user gets bored and closes application
the next day, user comes back and clicks your link again
application is already downloaded, so it starts right away
user gets bored again and closes your application
1 day later, you decide to update your application and you deploy the new jar file on your
server, replacing one of the old files
after 2 days user clicks your link again
java web start recognizes that the user has a different version, downloads update automatically and starts the application again
...
..
.