I'm working on a PWA that encrypts some data using Open SSL public key when the device is offline and sends it to a server when the device gets back online.
The issue is that if the code of the PWA is inspected the exact structure of the data could be revealed by the user.
Is there any way to hide the public key or a part of the javascript code stored on the user device in PWA?
No code in the client side can be hidden from user, if they choose to inspect, even after installing to home screen, it can be inspected in chrome dev tools.
All you can do is minify and obfuscate your JS files to give hard time for hackers. But not fool proofing it.
Related
I've a simple single page application written in just html/css/js. The content of the page is hard coded into the index.html file. I have a service worker so that the webpage can be downloaded and viewed as an app on a mobile device. I am trying to work out how is best to make sure any updates to the index.html file are reflected in the app version that is downloaded. From what I understand, if the user never closes the app, the updates would not appear on the app. Only after closing the app and then reopening it would the updated content be available. Is there a way to force the PWA to update its content even if the app is left open on a mobile device? Or a way to send a notification that an update is available?
Ajax technology must be used on your pages. The key to solving the puzzle is that Ajax loads the data in the background by using JavaScript and XML, so your page never needs to be refreshed.
There is no code to change, so the answer is very general.
Our company designs museum and visitor center exhibitory, and my main job is designing touch screen kiosk applications. Enamored by Vidya's introduction to Kiosk Apps using Chrome boxes, I quickly had my boss procure one for testing. I have since gained a firm grasp of Chrome App structure going though Google's tutorials (manifest files, MVC, etc) and have found the performance of our little HP Chromebox plus HTML5 development to be pretty impressive. I'm developing on my Macbook using Chrome Canary to run and test the apps.
I'm adding in this background information so you can better understand my goals. We of coarse need these apps to launch full screen upon power up. No login or user installation is desired. I prepare the boxes in my office, install them at the exhibit, the end. We certainly don't want our multimedia apps to be sitting up on the Chrome Web Store for others to download and install.
So, I've gotten to the point where I want to install a simple kiosk app on our HP Chromebox. Unfortunately Vidya did not go into detail on this part. The page from her article only touches upon adding kiosk_enabled" : true to the manifest file.
So here's what I've tried so far: I've moved my app folder onto an SD card and moved it from there onto our HP Chromebox into the "Downloads" folder (apparently the only folder). I sign into Chrome Browser on the box with my company account (do I have to do this?) and load up chrome:extensions. I click "load unpacked extension..." and select my app folder. The app installs and I am able to manually launch it by clicking "Launch". Next, I click the "Manage kiosk applications..." button and enter the app ID into the field. This is where I get stuck. Clicking "Add" produces an "Invalid Application" error.
Looking around the web I have found lots of confusing information:
I must "Wipe" the Chromebox in order to use a Ctrl+Alt+K key command to truly enable kiosk mode. (Google's instructions on how to do this stops with Samsung and Asus 'boxes, I have an HP, not to mention the "Manage Kiosk Applications" button is already visible to me).
I must upload my App to the Webstore as either public or unlisted, and then download and install it onto my Chromebox. Really? I don't want to sell my app or make it available to anyone. It is only meant to run in our exhibit. Our apps could be gigs of data with HD videos!
I must make my Chromebox "Managed" or "Enterprise" or "Enroll" it for Work and Education Administration. In most cases, we'll be installing one or two of the 'boxes to allow users to navigate though static HTML pages. I don't have a need to manage a fleet remotely (at least not yet). So, the aforementioned complications seem unnecessary, and expensive if I understand things correctly.
Can someone point me to the definitive process for achieving my goal of an auto starting, full screen kiosk application on my Chromebox?
I'm not an expert on this but kiosk apps are defined by "kiosk_enabled": true in manifest.json. What's important to know, though, is that from what I've seen they can work in three different modes:
If they are installed as an unpacked extension (for example, in development) they will be available as apps in your logged in environment and run but full screen mode. They're essentially "normal" apps except that they are full screen.
If they are installed using the "Manage kiosk applications..." button then they are available without logging in. On the log in screen at the bottom you'll be able to see the app and click to start it without logging in. However they won't start automatically. AFAIK you also can't load an unpacked extension in this way.
If you enable "kiosk mode" for Chrome OS then you can make kiosk apps auto start. At least on the Asus CB you do have to do the CTRL-ALT-K keystroke BEFORE you log in for the first time. This is for an unmanaged device. Now, when you load the app using "Manage kiosk applications..." in chrome://extensions and hover your mouse over it in the dialog you should seen a "enable auto-start" or similar button. You need to select this. Now, when you restart the system the app should automatically start. If you want to cancel this just as the app is loading you can press CTRL-ALT-S. A message indicates this on the screen, too.
Hope that helps,
Simon
Can't help you with anything related to kiosk, but you can generate a CRX file from the Extensions page on your development system, get that onto the Chromebox, put the Extensions page of the Chromebox into developer mode, and then drag the CRX to the Extensions page and drop it. You should see a dialog asking you if you want to install it. This is a completely different form of install than loading an unpacked extension and may get around whatever limitations you're seeing.
UPDATE: (1) Extensions page on Chromebox doesn't have to be in Developer Mode, (2) CRX to be dragged must be in the Downloads directory, not on Google Drive. Didn't test external device (SD card or USB drive).
In order to add your app from Manage Kiosk Applications, you will need to publish your app to the Chrome Web Store. If you don't want your app to be public you can publish it as Unlisted, which means that anyone with the link can install it. Unfortunately, if the app is published as Private you will not be able to add it as a kiosk app. [source]
Beyond that, the only thing you need to do to create a kiosk app is to include "kiosk_enabled": true in your manifest.json file.
I know I can use the apple-mobile-web-app-status-bar-style meta tag and after adding the web page to the home screen, it will run the app in full screen mode.
My question is if there is any tag, css or javascript I can use to tell mobile safari to do it directly, without having the user adding to the home screen first?
You could consider something like PhoneGap that deploys a webapp as a native iphone application. It would also allow you access to things like the accelerometer via javascript calls.
Currently, and sadly, this can't be done :(
There is a way of automatically installing 'webclips' on your idevice.
You do this by deploying a profile payload to your device (.mobileconfig file).
Payloads can be signed or unsigned, for testing purpose unsigned profiles will come up as Insecure.
https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurationProfileRef/Introduction/Introduction.html
The advantage using a profile like this is that you can set it so the user cannot remove the 'webclip' in the standard way, having to remove the profile to remove the app. You can also protect this with a PIN.
One reason I didn't use this method for registering my apps was that I couldn't get it working offline with appcache manifests (iOS6.x), however this may have improved since iOS7.x
I have a fairly standard ASP.Net web application which is used via mobile safari on the iPhone.
Some users who have a link to the web application placed on their desktop via profile are reporting that when navigating between pages (which I do on the server with Response.Redirect after specific events or via standard anchor tags in other cases (no target specified)) that Safari opens a new window instead of reusing the existing window.
Because of this, any login token/cookie etc (i'm using the built-in ASP.Net membership stuff), is now gone for that new browser window and the login prompt is shown.
The problem doesn't happen every time, and I can't seem to replicate it on my device (but i'm not deploying the shortcut via profile)
As you can probably imagine, it's quite frustrating for the users to have to log in every time, and you can't fix an issue you can't replicate.
My question is, has anyone heard of this issue and/or know a workaround?
The app is NOT iPhone specific, that is, it is used in a full desktop browser as well, and the logins stay like you'd expect there - and the same window is reused repeatedly.
I've considered a few possibilities, but have been drawing a blank as far as what might be causing this or how I can resolve it.
Do you have any iPhone meta tags set (to remove the url bar or the toolbar, for instance?) If you do, the phone will assume it's a native web app, and urls will open in a new safari window, like they would for any other native app.
If you are taking advantage of using the web app in full screen mode (where it is bookmarked to the launch screen next to native apps) you can prevent it from jumping out of fullscreen mode by and in to safari replacing type links with javascript.
location.href = '/yourPath';
This is a nifty trick which even works if you are linking to an outside URL, like doing an OAuth to Facebook and back.
I have a blog post on this here: http://www.aaroncoleman.net/post/2011/07/29/Keeping-iPhone-Web-App-in-Fullscreen-mode-from-Homescreen-Launcher.aspx
Can we build an Application using UIWebView that will entirely mimic the Safari Browser?
Are there any cases where UIWebview can not do what that can be done in Safari?
For one thing, you have a separate cookie storage per app. So if a user has some preferences at site X within Safari, it won't have those preferences at site X within your browser, and vice versa. Apart from that a UIWebView is very much like the real thing.
You cannot easily build an application that mimics the Safari browser using the public API exposed by UIWebView component. For one thing, please look at the UIWebView delegate methods. When you have frames inside the page you want to load, you may have a hard time telling if a user has clicked inside an iframe/frame or clicked on a link in the main document.
Dealing with authentication to site with invalid certificates is also hard with the UIWebView component, especially when the site with invalid certificate is reached by clicking a link inside an iframe.
Rendering content in UIWebView will be much slower than it is in Safari.
Safari's Javascript engine uses a "just in time" compiler. It takes the incoming Javascript code and transforms it on the fly into machine code that can run directly on the iOS device's ARM CPU. This allows Javascript code to run at a speed similar to a native app's code.
The problem is that Apple doesn't trust third-party developers with this power. If a third-party app had the power to convert Javascript into machine code and run it, that app would also have the power to download and run other pieces of machine code—and Apple would never get the chance to review that code. Once App Review approved it, (developers/hackers) can change the downloaded code into something that logs your passwords or something. And there's no way to grant this power only to UIWebView and not to other parts of an app, because UIWebView runs in the same process as the developer's code.
So basically Apple forbids this because allowing it would break the security provided by the App Store and make iOS more vulnerable to attack. They can allow it for Safari because they control what Safari does, but they can't trust others not to abuse that ability.