We're developing an app that will be running embedded within a browser using secure sockets to communicate with a server. I want to add the ability for the applet to save its state (locally) so when they next open the page, the app can recall where the user was.
I've been looking into CookieManagers and Java Web Start with JNLP, but I'm unsure where to begin and what would be the best solution.
Any reccomendations? :)
Accomplished using self certification now. The user grants the application permission and then the application can read and write from the file system.
I used this article for signing the app: http://www.jade-cheng.com/uh/ta/signed-applet-tutorial/
Related
Is there a way to authenticate a java desktop application with Slack using OAuth2? I am trying to follow Slack's guide.
I am getting stuck because it says you get the access token inside of the redirect uri of your application. But since the app I am making does not exist inside of the web browser, is there anyway I can do this?
Can my java application launch a localhost site that it can communicate with to use as the redirect uri? If so, how?
Desktop app as internal integration
Before we get into more details please note that there is an easy solution if you plan to use your desktop app for your own Slack workspace ONLY. In that case your app does not need to support the full Oauth work flow and you have two options:
Install your app as internal integration via the management page
of your Slack app and then copy & paste the token to your desktop app
Create a legacy token for your Slack workspace and then copy & paste to your desk (not recommended)
I also like to clarify upfront that your app only needs to run the Oauth process ONCE for installing it into a new Slack workspace. The resulting token has no expiration date and has not to be refrehed.
Desktop app for multiple Slack workspaces
If you plan to distribute your desktop app to multiple Slack workspaces you will need to support the full Oauth installation process.
Slack is using Oauth 2.0, so in principle all the standard answers from this older Oauth wiki article should work for Slack too.
However, since you can not assume that the local machines of your users are reachable from the Internet (e.g. redirecting back to a local web server will not work, since Slack will most likely not be able to reach it), you will need a web helper app that runs on a web server and is reachable from the Internet.
This web helper app is basically a small web site, which performs the complete Oauth dance for the installation process into a new Slack workspace. You app can open a browser window and redirect to the web helper app to start the login process. You then have two basic approaches how to handle the connect back to your desktop app:
Show the resulting token to the user and ask him to copy & paste it
to your desktop app (simple approach)
Store the resulting token in your web helper app and provide an API to your desktop app to fetch it automatically. (user-friendly approach)
If you are looking for a starting point for such a web helper app, take a look at this example PHP script for installing Slack apps.
First of all i will describe my problem, i'm making an app that will provide the service to upload pictures into a server folder called "uploadPhotos". my app and the uploadPhotos folder are stored physically in diferent servers, so i need a way to define in my app the windows network security credentials so when i try to upload a photo, the app would connect to the other server with the credentials provided and store the photo in the uploadPhoto folder.
i'm using glassfish 4
Morning,
You should use LDAP to connect to the Windows Domain Server. You can use this to authenticate Active Directory credentials. One way to do this is to have the Windows Domain Server perform the authenticate for both other servers. This would maintain credential compatibility between the two.
a link! has a little bit more information.
I'm building a Play! framework application and i'm required to implement a pki authentication with a smart card. I've been searching for a few weeks and can't seem to find exactly what I'm looking for.
I want that with the client entering the site a window will pop that enables the client to enter his smart card PIN code in order for him to authenticate to the app. After the client enters his PIN code the app will verify him if the code is right and recieve the identity from the card and from that point he will be able to continue freely.
Your web application can not interact directly with your smartcard as it is executed in the sandbox of the browser.
There is no built in API in JavaScript/HTML5 to access smartcard.
So you have to build a bridge between your smartcard and your application. The most common in java is to build an applet that will interact with hardware and expose Javascript methods.
I recommend this article to be read : http://tech.springcard.com/2010/java-pcsc-accessing-smartcards-from-a-web-page/
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
...
..
.
I'd like to create a service where people can enter external websites, after which the returned source will be modified by my application (for whatever purpose) and then returned to the user.
One would normally redirect all traffic through the server, so that the server is the one accessing the external source. This is because HTML5 and flash sockets cannot access external sources unless the external source has the required policy files (please correct me if this is false). Even if the user wants the client to, it still can't access these external sources if the external source itself does not have such policy file.
My question is: can a Java applet access an external source regardless of it's policy file, if the user allows it to? How is this usually done?
If not, is there anything else I can try? Redirecting all traffic through my server is not an option because of 1. high use of bandwidth and server resources for a free service and 2. a high chance of my server being marked as a spam bot or bandwidth hogger.
Thanks in advance.
Regards,
Tom
If choice of technology is not a problem you can use a Java Web start application.
Your application will be launched from a web page (if that is what you want)
After user-confirmation your application can do everything (similar to native apps)
I have actually done this with a Java web start application that used web services from servers other than the one it was launched from.