I have a question about Firebase's offline capabilities for JavaScript. Specifically, I am wondering if one were to lose connection while filling out a form on a web application (powered by firebase, obviously), and then try to send that form, would it perform a write operation to the local database, and then catch up with the server when connection is re-established, or would that data be lost? If this is a yes, I am assuming that it does not matter if the user exits out of the page, as long as the form as sent.
I know that it offers tremendous disk persistence for its iOS and Android SDKs, however I am just trying to get a better handle on how this can help in JavaScript. I am aware of the onDisconnectclass, and that it should mainly be used to manage the presence of a users as well - Just has this on mind for a while!
Thanks !
Firebase supports two types of offline mode:
in case of intermittent loss of connectivity, the client will keep serving events from the local data and any writes will be queued. When the connection is restored, all writes are sent to the server and any stale data is resynchronized. We often call this "tunnel mode".
The mobile native (iOS and Android) clients can be configured through their API to store all data on the local disk. In case of prolonged loss of connectivity, these clients will then queue writes on disk too. The client will also be able to serve data from this disk cache, when the app is restarted. This one we often call "airplane mode".
Tunnel mode is available in all Firebase SDKs. Airplane mode is only available in Firebase's native mobile SDKs for Android and iOS.
Related
I am tasked with converting a PHP application into a progressive web app. This entails converting the existing PHP logic into JavaScript that runs client-side.
However, the PHP application contains sensitive information, including SQL credentials, which must never be leaked. This complicates the conversion because one of the biggest requirements of a progressive web app is Offline First, or the ability to operate without an Internet connection and/or not slow down even if an Internet connection is available.
Encrypting the JavaScript code is not an option because, no matter how strong the encryption, the decryption code must be shipped alongside it, and thus, determined hackers will always be able to crack the encryption. HTTPS cannot prevent hackers from jailbreaking their phones.
On the other hand, sending an Ajax request to a proxy server that holds the sensitive credentials will slow down the application, defeating the whole point of progressive web applications.
I have spent hours looking up solutions online, yet nothing I found is relevant enough. So how should developers go about ensuring that SQL credentials and other sensitive information are never exposed in the progressive web app?
EDIT: I should clarify that, while I understand that synchronizing local data with server data is the preferred behavior of progressive web apps, I am explicitly forbidden from doing so in this particular case. The data must be kept confidential.
To answer your original question on how to store your DB passwords safely in client side, "you can't". Anything at client side is not for sensitive information like server side DB password.
PWA is a web application end of the day with new features. But those doesn't gives you any added security to perform server side like operations which you can hide from users. Even if you use HTTPS, it will only encrypt data over network.
What if you use: If you store "DB password" in a PWA app or any web app for that matter, user can get the password using Chrome Dev tools for example and use that to connect to DB directly to get all the data in it, not just his.
Solution: PHP is a server side scripting language. When you convert that to HTML/JS, server side code from it will be remaining for your to put it again in server side itself and expose the data using web services to PWA.
On Downloading data: Caching is not plainly equivalent to downloading. Read more on here and if you still don't want caching, you "Network only" mode as explained in the same link and make use of other PWA aspects..like notifications, install to home screen.
I need to build an application for mission work that runs 100% offline and then syncs up with the server when it reconnects to the internet. The application "currently" has over 6k people in the database that needs to be searchable when the missionaries are in the field. The challenge is that I need "all" of the data local and disconnected on multiple laptops or tablets. I know I can use a database like CouchDB but I would much prefer use firebase or something similar to keep the management of the system simple. Is this possible with Firebase?
Thanks!
The web client can handle intermittent offline (will work offline, but won't survive a page refresh), but not persistent offline like the native SDKs can.
If your web app needs specific offline functionality, look into using ServiceWorker and IndexedDB. You can create a persistent offline cache of data for offlne functionality.
Jake Archibald's Offline Cookbook is a great resource for building offline web apps.
I have a AngularJS app (embedded in a Cordova app).
To get and set data, it uses a REST API (that runs on a Django backend server).
I need that the app keeps working for several features even if the network is down.
For example, I'm expecting this kind of behaviour:
Online Mode
A client does something in the app
a POST request (to create data) is sent to the API
The client gets a "Thank you for doing xxx"
Fallback offline mode
A client buys something on the app
The client gets a "xxx can't be done right now, but it will be done as soon as possible"
Nothing can be sent to the server since we're offline. So how to do? Is there a way to put the API requests in a queue that will be executed when we're back to online mode?
How would you technically design this? It seems there is lots of differents technologies for offline mode, and it's a little bit confusing to me. Any guidance would be welcome.
Thanks a lot.
I would like to use such app, that would make me feel stupid. But there is
You can check network status with this plugin.
https://github.com/apache/cordova-plugin-network-information/blob/master/doc/index.md
Each request will need a switch between sending HTTP POST and saving POST data to local storage.
Then you would just create callbacks for following events:
document.addEventListener("offline", onOffline, false);
function onOffline() {
// Turn on saving to local storage
}
document.addEventListener("online", onOnline, false);
function onOnline() {
// Read local storage, send all requests
}
I'm not sure what the pressure in the comments are not to do this. We have this functionality in an app we are developing.
Basically we package up the iOS app as a Cordova wrapped web container and also run a local proxy server as part of the app. It passes all data through it to the web service. If the requests fail, it returns an identifier to the app so you can determine that the connection to the server is down, and the app then saves the requests to localStorage. That way the UI can adapt to being in "offline mode." you can later push data from the app through the proxy once the connection to the server is restored. The app connects directly to the proxy rather than to a webservice.
As far as I'm aware, there's not an easy library to solve this situation though, and you have to be aware of how the requests will affect the online application (can things go out of sync in your system, if the user runs requests that are cached until later?)
It is definitely something that can be done, though.
I'm creating an app where the server and the clients will run on the same local network. Is it possible to use web sockets, or rather more specifically, socket.io to have one central server and many clients that are running native apps
? The way I understand socket.io to work is that the clients read the web-pages that are served from the server but what happens when your clients become tablet devices running native apps instead of web pages in a browser?
The scenario I'm working with at the minute will have one central server containing a MEAN app and the clients (iPads) will make GET requests to the data available on the server. However, I'd also like there to be real-time functionality so if someone triggers a POST request on their iPad, the server acknowledges it and displays it in the server's client-side. The iPad apps will (ideally) be running native phonegap applications rather than accessing 192.168.1.1:9000 from their browser.
Is this technically possible to connect to the socket server from the native apps or would the devices have to send POST requests to a central server that's constantly listening for new 'messages'? I'm totally new to the whole real-time stuff so I'm just trying to wrap my head around it all.
Apologies if this isn't totally clear, it's a bit hard to describe with just text but I think you get the idea?
Correct me if I am wrong.
You have multiple iPads running native app. They send a POST request to your node JS server which is running in a computer in the same local network. Whenever the server receives a request from app, you want to display that a request has been received in your computer screen.
If my assumptions about the scenario is correct, then it is fairly easy to do. Here are the steps to do it.
Create a small webpage (front end). Load socket IO in the front end page like this -
<script type="text/javascript" src="YOUR_SERVER_IP/socket.io/socket.io.js"></script>
Then connect to server using var socket = io(). This should trigger connection event in your backend.
Handle all POST request from apps normally. Nothing special. Just add a small snippet in between. socket.emit('new_request', request_data). This sends new_request event to front end.
Handle the new_request in your front end using socket.on('new_request', function(request_data) { ... });. That's it. No need to add anything to your native app for realtime update.
The second step would be a little complicated as it is necessary to make socket variable available inside all POST requests. Since you chose node.js, I don't think you need any help with that.
Not totally clear on your project, but I'll try to give you some pointers.
An effective way to send data between native apps and a server is using a REST server. REST is based on HTTP requests and allows you to modify data on the server, which can connect to your database. The data returned is typically either JSON or XML formatted. See here for a brief intro: http://www.infoq.com/articles/rest-introduction
Android/iOS/etc have built in APIs for making HTTP requests. Your native app would send a request to the server, parse the response, and update your native UI accordingly. The same server can be used from a website using jQuery ajax HTTP requests.
Express.js is more suited to serving web pages and includes things like templating. Look into "restify" (see here: mcavage.me/node-restify/) if you just want to have a REST server that handles requests. Both run on top of node.js (nodejs.org).
As far as real-time communication, if you're developing for iOS look into APNS (Apple Push Notification Service). Apple maintains a persistent connection, and by going through their servers you can easily send messages to your app. The equivalent of this on Android is GCM (Google Cloud Messaging).
You can also do sockets directly if that's easier for you. Be careful with maintaining an open socket on a mobile device though, it can be a huge battery drain. Here's a library for connecting ObjC to Socket.IO using websockets, it may be useful for you: https://github.com/pkyeck/socket.IO-objc
Hope that helps!
To answer your question, it is definitely possible. Socket.io would serve as the central server that can essentially emit messages to all of the client. You can also make Socket.io listen for the messages from any of the clients and serve the emitted message to the rest of the clients.
Here's an example of how socket.io can be used. Simply clone, npm install, and run using 'node app.js'
All you have to do is to provide a valid server address when you connect your socket from the iPad clients:
var socket = io.connect( 'http://my.external.nodejs.server' );
Let us know if you need help with actual sending/receiving of socket events.
It is possible to connect to Websockets from your apps.
If you are using PhoneGap then you need a pluging that gives support to websockets in your app (the client) and then use websocket like normal way using Javascript see this.
If your app is native iOS look into this it could help you.
The primary use of the Sockets in your case is to be a bidirectional "pipe" between an app and server. There is no need of server sending the whole web-page to the native app. All what you need is to send some data from server to the client(app) in response to POST (or GET) request and then using this data on client side to update client's UI in real-time. If you are going to use moderate amount of devices (say tens of them), you may have connected all of them to the server permanently keeping individual socket connection open for every individual link server-to-app. Thus you may deliver data and update client's state in real time.
In fact web browsers also employ sockets to communicate to web servers. However as in general case there is no control on amount of concurrent clients in Internet, for the sake of limited networking resources conservation, servers do not keep sockets open for a long time, closing it just after the web-page was sent to client (or timeout has expired). That's how HTTP protocol works on the low level. The server waiting for the HTTP clients (browsers) by listening the 80 port, responding them by sending the whole web page content, then closing the connection and keep waiting for another requests on the same port.
In your case it's basically a good idea to use socket.io as it's a uniform implementation of sockets (ok WebSockets) on both client and server side. The good starting point is here
Ultimately what I would like to to is build a Javascript app that runs in the browser, and is able to communicate to other users running the same Javascript app on other machines within the same network. I've been reading up on and playing around with Websockets and webRTC, but they both require a server at some stage of the connection process. I have also looked at PeerJs and OpenPeer, but they too seem to rely on webRTC which in turn requires an intermediate server to setup the connection.
If the users are not connected to the Internet (or to a network running a local server) it doesn't seem possible to use either of the above techniques, right?
Basically what I'm thinking is this:
User A and User B are on two separate machines on the same LAN/WLAN, not connected to the Internet.
User A opens up the app/page in his browser.
User B opens up the app/page in his browser.
User A enters User B's local IP address in a textbox and clicks on "Connect".
User A and User B can now send messages to each other.
Is this possible today? Or is there something being developed that would enable this in the near future?
This is not possible to do directly inside of a browser.
Standard HTTP interaction is based on a request-response model. Web browsers act as the client, sending requests. They are not designed to be able to handle HTTP requests and send responses accordingly, that job belongs to a server.
I know this is an old question, but in case someone finds it relevant:
Today this is possible using WebRTC, a JavaScrip, peer-to-peer, real-time communication protocol.
A library that's available at the time of writing is PeerJS, which supports most browsers, for now except Safari.
PeerJS handles some of the complicated, behind-the-scenes stuff related to NAT and firewalls so that you can send data between two JavaScript clients.