Is there any way to share a session between a java web app and an AIR app that uses blazeDS? The goal is some kind of single sign on, so when either one of the apps is logged into that the user would not need to log into the other. They're both running in the same tomcat, but they are different apps.
use local connection and make them talk to each other and share their status.
Related
I'm working on a Project which aims to develop an app for a bloomberg anywhere subscriber. We have a Framework available, which we usually use to write our apps. These run ususally on a cloud as webapplications.
As apps using bloombergs open API can only run on the same machine as the subscriber is logged in biometrically, due to data acess restrictions and prohibition to distribute the data further, we plan to run our framework locally on the clients machine as a desktop application, in order to use the tools we are familiar with.
the back-end, which would use the bloomberg open api to get the data from the local interface provided by the local bloomberg-software, runs on a tomcat-server. the frontend is a javascript client, accessing the back end via API-calls locally.
My Questions are:
As bloomberg data-access is very restrictive, i'm wondering whether the bloomberg-interface accepts calls which come from a server software (like tomcat), even when running on the same machine an not used to distribute the data further?
Would set-up: framework running on a second machine (linux, its easyer to run there), calls Bloomberg Port on first machine via private local network, data not leaving second machine, be possible 1. technically and 2. legally?
Does anybody know that? Any advice highly appreciated, many thanks in advance!
We have a java based web application. The web application is used to conduct exams. Is it possible to run the application in kiosk mode so that when students are accessing it, its opened in a kiosk mode so that students cant do anything else on the system till the exam is going on.
The kiosk-ness is purely a client side phenomenon. The server side webapp doesn't know or care about that, as it just serves requests.
Even if it did know, it couldn't reliably prevent the user from doing forbidden things. Generally a kiosk-mode application isn't a webapp, because it has to prevent things like running outside applications, going to user selected URLs, and other such things which are a lot easier to block in a native application than inside a browser window.
I have created database in one application and that application is installed in multiple devices.My requirement is that if i change the value in database of one device then,that changes in database should reflect in another device of same application.I need it without server/third api.
Thanks in advance...
This is precisely when one does need a sever.
Stop and consider what it is that you are asking for. You need a way for a phone to notify all other phones that hold the same application about a change. Phones are not directly addressable to each other via the web, which makes any kind of peer to peer algorithm tricky. SMS texts is the closest form of direct addressing that phones do support, thus it could be used to build a peer to peer protocol, but that would be tricky, unreliable and is unlikely to be beneficial.
A server on the other hand is the standard approach to solving this problem, the server acts as a shared agent that all phones that connect to the web can address easily. Even if the server is just an FTP server on a freebie hosting site.
You need to implement a server functionality in your android application.
What is a server : A server is a running instance of an application (software) capable of accepting requests from the client and giving responses accordingly. Servers can run on any computer including dedicated computers, which individually are also often referred to as "the server".
For further information,I would like to provide this link which will clarify you about communication between two devices Android - communicating between two devices (Use of bluetooth etc.)
When developing a Java EE 7 webapp (Win8, eclipse Kepler, JBoss Tools 4.1.1, wildfly8.0CR) I can use the application at localhost:8080/app/
But I wonder what to do, if I want an extern access to that app, e.g. from my other PC. What configuration is needed, or do you need a "real" server for such a purpose?
Thanks in advance
How public to you want your website to be?
If you want to access it from another computer on the same network(for example your home network) you need to adjust your network and firewall settings so that that you would have access from one computer to anoher on the same network. Then if on the computer that contains the app you would access it for example http://localhost:8080/myapp then on another network you would access it http://ip-of-the-comuter-that-contains-the-app:8080/.
If you would like to access it from outside the local network then the process is same, but a static IP would be recommended to the computer that contains the app.
If you would like the general public to use the app, then hosting it from your PC may not be such a good idea and somekind of server solution is adviseable. There are lots of different cloud solutions like http://aws.amazon.com/ec2/ or https://developers.google.com/appengine/ that would provide enough flexibility for majority of apps. Or you could ofcourse have your own server hardware, but this can turn out to be much more expensive to keep stable and secure.
For a quick-and-dirty solution you can choose the "Enable remote access" option on the server (double click the server, and you should see a check box in the server editor).
This will tell the server to start listening on all network interfaces and not just the local one.
btw. we only listen on local network interface by default for security reasons since we don't want you to unintentionally get hacked if a vulnerability is found and used by someone malicious.
I wanted to code a web application, where one user can choose a file and other multiple users can download that specified file off of that user's computer. That user would have to leave his computer on and leave the web page open.
I dont want to have a big main server that has to handle all that traffic. That user's computer is the server, persay. I understand I'll use torrent.
All this has to be done on a website.
Will a web socket work?
Please and Thanks.
This really isn't possible for a variety of reasons:
Firewalls / NATs
Dynamic IPs
No "server" running on the user's machines
Permissions on the user's machine
What happens if the user simply deletes the file on their machine?
To actually make it work you'd have to:
Convince the user to install the app on their machine (you'd need a windows/linux/... EXE)
Get the user to open a port in the firewall (or use some library to enable NAT passthru)
Have the user's PC ping your server in the event the user's IP changes
On the server side, you'd have to keep several database tables, here are few I can think of off the top of my head:
A user's table (user ID [PK], Current IP, Communications Port, (maybe some other tracking things))
Available downloads table (download ID [PK], user ID [FK])
Then when someone wants to go off and download, you have to (probably) launch your app with the requisite arguments (remote user's IP/port/file ID) and have that do the work of the download.
This is by no means an easy feat.
If by WebSockets you mean the HTML5 variety, I'd stay away from that. http://en.wikipedia.org/wiki/WebSockets#Browser_support
The the computer that has to stay on, is basically your server. Even if it isn't a big server somewhere.
My suggestion would be to install apache or some other small web server on each users computer and have have a dyndns address for each computer so you can find each other. it would be much easier than coding something. especially if it has to be through a web page.
You could use a c# client library to interface to bittorrent or etc and use this mode to upload/leach. As far as NAT/Firewall issues go they are well documented and a function of the protocol being used, ie deal with it.