My corporate VPN blocks all external traffic from an Android device. I am trying to test PWA that is internally hosted (all resources inside a firewall). What I observe is that despite passing Lighthouse audit my PWA fails the WebAPK creation process on a device. Specifically, the install process takes a long time, and eventually it degrades to an application shortcut install.
What I did:
Built the simplest PWA that I could think of (index.html registering service worker + sw.js with fetch even handling index.html request offline + web manifest) and hosted it on an internal server
Run Lighthouse audit on the desktop and made sure it passes all PWA Lighthouse audits
Run bubblewrap init on the manifest to double check that icons/names are OK
Tried to install PWA on an a Pixel phone from Chrome's dot dot dot menu behind firewall
After a long time, the application shortcut was installed (with Chrome overlay icon)
Checked chrome://webapks/ on my phone - no surprises here, I did not find WebAPK for my app
Turn on my corporate VPN workaround, which allows me to bypass VPN restrictions and access external addresses (rooted phone + ProxyDroid hackery)
Now WebAPK creation works
Question 1:
Could someone please explain what is involved in WebAPK creation that would make it fail behind a strict corporate firewall? Is there any external resource (a service perhaps?) involved here that I could advocate my corporate VPN to whitelist? If not, any advice of how to have automatic tests for WebAPK creation would be appreciated. I thought of using bubblewrap build, but, since it is for TWA's, I did not expected it to pass for my simple PWA.
Question 2:
In general, what is the best technique for diagnosing WebAPK creation failures for PWA's that pass Lighthouse audit?
The WebAPK is generated server-side by Chrome. Chrome sends details from the manifest, along with the icons to it's server, which then returns the WebAPK. As you pointed out, it's most likely your corporate firewall is blocking that request to the server, preventing Chrome from generating the WebAPK.
The code for generating WebAPKs in Chrome can be found here
For your second question, we don't really have good tools for debugging that, if Lighthouse passes, it should build the WebAPK (with the exception noted above). I suspect you could connect the device to your computer and use ADB to look at logs, but thats... ugly. Sorry.
Related
I'm building a PWA with Nuxt.js that uses the Web Serial API to communicate with our proprietary hardware. It works as expected (i.e. the port will be available without user action the next time you load the web app unless the browser security is reset) on Windows 10/11 and macOS devices, but the device this application will be running on is a Raspberry Pi 4 running the latest stable Rasbian release. On the only two browsers I've found that can run on the Raspberry Pi and support the Web Serial API are Chromium and Vivaldi. In both of those browser, there is an issue remembering which port(s) the user has already allowed access to.
In Chromium, even a page refresh will cause the port permissions to reset, requiring the user grant access to the serial port again. In Vivaldi, the permissions can survive a page refresh, but restarting to browser will cause it to forget any prior port authorizations.
I have not been able to find any option to whitelist websites in the browser settings the way you can for some other security/privacy options, like you can with things like website clipboard access, nor any way to disable the security feature altogether.
This will be running on custom hardware that ships with the software, so there are no limitations to what can be modified to resolve or work around this. The device is touchscreen only, and the app will be running in a fullscreen kiosk mode at boot. There just needs to be some way to prevent the user from needing to select a port like /dev/s0 and grant the web app access to it every single time they turn the device on.
I have a PWA that I am trying to use to create an Android app (apk) with a trusted web activity using bubblewrap tool (https://github.com/GoogleChromeLabs/bubblewrap). To check the PWA criteria, it uses Lighthouse which fails the following audit step (red):
start_url does not respond with a 200 when offline
Timed out waiting for start_url to respond.
But actually the step regarding to current page being offline is ok (green):
Current page responds with a 200 when offline
My PWA is hosted at an url: https://example.com/myapp/. So the service worker (manifest) has the startup url and Scope at "/myapp/". So if I access this page in Offline mode (Check the box "Offline" in the dev tools "Application" tab) it serves an offline page that is cached at the beginning when the service worker is installed (I followed this example: https://developer.mozilla.org/en-US/docs/Web/API/Cache/match and everything seems to work fine, I tested even on my mobile in airplane mode).
Also, the startup page redirects to ?locale=en but it is the same webpage (so in Offline mode every url seems to show my offline html page). What is even stranger is that in about 20-30 audit reports, one time this step passed, randomly)
I am doing the Lighthouse tests on Mac, Chrome 84.
EDIT:
So I made some tests and I saw that if I access http://example.com/myapp (instead of http://example.com/myapp/ - there is a / at the end), the offline html page is not shown anymore. But in the manifest the scope and start_url are set to "/myapp/" exactly so I don't know if this is an issue (if I set them to "/myapp" the PWA won't work anymore saying that there is no service worker at that path, which sounds strange because my jetty server redirects /myapp to /myapp/ which both should be the same resource)
The Bubblewrap lighthouse check is a wrapper around the [Pagespeed Insights API]. The PSI API can be a bit flaky and fail to run at times. If the failure is constant, I'd recommend running the URL against PSI, as you should get the same report, but with more detailed information.
I’m interested in finding out exactly what network requests are made by certain 3rd party Chrome apps. I can open the Dev Tools from chrome://inspect/#apps, or from the context menu (enabled under chrome://flags/#debug-packed-apps), or by means of the Chrome Apps & Extensions Developer Tool. Whatever I do, the Network tab stays blank except an occasional image/png, while I’m sure lots of HTTP requests (or HTTPS to be exact) actually take place.
How can I monitor all network requests that an app makes? It seems easy for extensions, but not for standalone apps. Or is MITMing myself with a proxy with a self-signed certificate that Chrome is configured to trust the only option?
I habe a web role in azure. It is running fine locally in development app fabric, but fails silently when deployed to Azure (simply no response at all for any request).
I assume it's some problem with the web.config, but that is happening so early that it occurs already before I can set up the diagnostic stuff in global asax. As said, it's working fine locally, but there is simply no response at all from the azure system.
How can I find out what specifically is wrong to be able to solve it like get the exception text, stack trace, IIS application system error log or anything that could hint me to the real problem?
The absolute first thing that is run in a Web role is not your application but the OnStart() method in WebRole.cs in your Azure project. This is the place to add code to monitor your Web site.
The standard technique is to copy your application trace logs and the Windows event logs to Azure table storage, together (if appropriate) with instrumentation for CPU usage, IIS statistics and what-have-you.
A good introduction to this is here: http://blog.bareweb.eu/2011/01/beginning-azure-diagnostics/
and a good followup with details on the specifics you'll need in your application is here: http://blog.bareweb.eu/2011/03/implementing-azure-diagnostics-with-sdk-v1-4/
which remains applicable for the Azure SDK 1.5.
Once you are capturing diagnostics, you can either use Visual Studio to view them directly, or you can use a tool like the Cerebrata Azure Diagnostics Manager to graph and filter them automatically. This tool is a little rough around the edges (especially for larger systems with multiple instances: the graphs aren't really useful) but is as good as it gets at the moment.
An alternative approach is to use Remote Desktop to connect to the remote instance and do some spelunking in the Windows event logs and suchlike. You can also use the Internet Explorer browser that's on the remote instance to directly connect locally to the application and see any errors etc. that may otherwise be hidden.
Personally I'd only do this if the diagnostic storage mechanism isn't working: production servers really should have remote desktop access turned off altogether to reduce the possible surface area for external attack.
Setting up diagnostics is the best long term solution to dealing with tracking errors in your application. If you want something a little more ad-hoc you can either catch the errors and write them to blob storage or use your own light weight trace listener.
I work in a service organization where users of our internal tools are often disconnected. It is often the case that service engineers on service assignments are "stranded" with an outdated version of some internal tool.
These tools are deployed using ClickOnce publish VS2010 .NET4 . If the users run all their apps while still connected to corporate network, they would get a notification that a new version was available. As the number of various tools increase, the chance increases that some app is not updated.
Is it possible to automate this process, by a batch file or something?
So that the engineers just need to run one file when connected to corporate nw to get all the newest versions of their installed tools?
Added:
An easier way of saying it would be to have "something like Windows update" operating on corporate net, but for internal ClickOnce apps.
Very interesting question. I can't think of a quick way to do this, but it's definitely possible.
I would create another ClickOnce app whose job is to update the other ClickOnce apps. This app needs the url of each app's .application file. If all engineers are supposed to have all apps, that's easy. If not, maybe you could look through their start menu and find all the ClickOnce Application Reference files. Those files contain the url.
Next, just launch the url and pass a query string argument...
http://server/MyApp/MyApp.application?UpdateOnly=true
In the startup of your applications, you can check the query string argument and shut down the app if it's run with UpdateOnly=true.
One side note. If you set the minimum required version of each of your apps to the latest version, users won't get prompted with the new version dialog. Seems like you'd want to do that or the user would still have to pay attention and do a lot of clicking.