PWA Development

[de la Rosa]

Hi,

1. The requirement that PWA be in HTTPS, will it matter if it has a self-signed certificate (meant for Intranet deployment) ?

2. Will it be limited to native/hybrid/disconnected apps or will it also work with web apps?

3. How does it differ to a web app that was "pasted to home screen" thru the browser considering the all the resource files would have also been downloaded when accessed, assuming no local database access ?

Vic

[DonRidley]

1. Yes.  Get a free cert from Let's Encrypt

2.  No/Yes

3.  I think, by definition, a true PWA has to have the ability to store data locally.  If it doesn't, it's not a PWA. 

Google's PWA Baseline Checklist:

https://developers.google.com/web/progressive-web-apps/checklist#baseline

That is a very good read.  NT11 Apps has all the tools you need to build an iOS,Android, and PWA.

Watch the recent Friday webinars and user group webinars if you haven't already.  They are VERY informative.

Good luck,

Don

[Wolfgang Orth]

1. Yes.  Get a free cert from Let's Encrypt

Don,
the question was about "self-signed" certificates.

You have to imagine that in some cases such a server will not neccessarily have access to the Internet. Some installments are separated from teh web, are accessible only from inside the LAN. So, if the server can't auto-renew the certificate every once in a awhile, there is no other solution rather than self-signing.

I hope that makes sense.

Wolfgang

[Jane]

I don't know the answer, Vic, but of course that won't stop me from opining.

We have an analogous situation - not involving PWAs but rather where we have a NetTalk webserver app that needs to be run on ChromeBoxes (where we can't import certificates) managed through Rise Vision.

So we use a store-bought Godaddy cert.

Of course, you can't get a public cert for a machine that's on a non-public domain (www.mywebserver.local)

Soooo... 
1.  We buy an "extra" public domain just for convenience purposes (MyDummyDomain.me).
2.  Use that "extra" domain to buy the cert we need (www.mywebserver.MyDummyDomain.me)  This is NOT actually a server that is accessible on the Internet.  --  Actually, we use this enough that we bought a wildcard *.MyDummyDomain.me cert rather than hassling with multiple Subject Alternative Names.
3.  Create a one-machine domain in our Active Directory DNS (forward lookup zone called "mywebserver.MyDummyDomain.me").  (We create a separate one-machine forward lookup zone for EACH webserver where we're using this trick.)
4.  In that one-machine domain, create a Host(A) record leaving the name blank - as the window says, "(uses parent domain if left blank)".  Give that A record the address for the web server.
5.  Apply the Godaddy SSL cert to the web server.

In practice, I also create a certificate on our in-house Active Directory-trusted certificate authority with the internal LAN name for the web server, and apply that certificate to the web server as well.

It's a bit Rube Goldberg, but all is happy for both domain-joined Windows machines using the internal LAN name and for the non-domain ChromeBoxes using the MyDummyDomain.me URL.

jf

[DonRidley]

Ah.  I see the word intranet now.  Eyes are getting old.

So, in a LAN environment, I think it could possibly work but may require additional work allowing the service worker to trust the certificates which, I assume, would be self signed.  You may also be required to setup exceptions in the user's web browsers to ignore certificate errors.  I don't know if the extra effort would be worth it when it's so easy to setup a publicly visible web server and use a "normal" certificate.

I'm curious to hear Bruce's answer.

Don

[de la Rosa]

Thanks for the responses guys but here are the constraints:

1. We are dealing with customers with several branches interconnected thru a very unreliable Intranet. While consolidation of data can be adequately serviced by an NT disconnected app, centralized data access is impractical as it may take too long ( can stretch more than 24 hours) to sync.

2. Internet access is absolutely out of the question as far as IT ADMIN is concerned.

3. We have an app server in each branch running NT webapp servicing fixed and mobile counters.

4. The objective is to give the branch's clients a more "digital experience" <BG> thru their mobile devices(phones/tablets) by allowing them to access their day's transactional interests while waiting for their turn to be serviced by the counters. While this is already possible with an NT app, it would be ideal that a client can have a uniform launching interface (app-like) when transacting in different branches (while connected to different branches app server). Ultimately, would like to be able to send push notifications to the branch's client mobile devices directly from the branch's app server.

Offhand, I am wondering whether launching a PWA will at least feel more app-like such as having it's proper icon and whatever advantages it has compared to a "save to home screen" browser shortcut.
 
Thanks,
Vic

[DonRidley]

1.  I'm sure the bank has a lot of tables to sync but the NT disconected desktop/app will only sync the records that have been changed and it's pretty quick.  You also have complete control of how many records can be synced at one time via the syncmethod's parameters.  It may be faster than you think.   

2.  I understand that constraint.

4.  If the customer only had access to the database when they're in the branch, they would have to sync their app everytime they came in.  Of course the mobile app would have a smaller snapshot of data to sync and that would be quick to sync.  As I said before, you have control over that.  It just occurred to me that each mobile PWA will have to point to a sync server.  A different one at each branch.  I don't know how you would make it work since the customer could go to different branches.  How would the PWA be setup to sync to each different sync server?  Hmmm...interesting. 

I wonder if you could have one public sync server that only syncs a small subset of the database that the customer's sync to.  Basically, the public sync server itself would sync with the main sync server but only the records you choose.  Maybe you could talk the admin into doing that.  I would laso mention to them that NT servers are VERY secure.  Bruce talks about that during last Friday's webinar. 

Don

[de la Rosa]

Right, Customers may or may not have multiple networks but if they have they also have levels of priorities and this particular application may be considered non-essential at the moment. The customer who wants it now doesn't have such high availability network. However, it is not a show stopper thanks to NT disconnected apps but just a constraint we need to live with for now. But PWA sounds to be an enabler bypassing the stores for one, so I guess just have to try it out and see.

Thanks,
Vic

[Bruce]

>> 4. The objective is to give the branch's clients a more "digital experience" <BG> thru their mobile devices(phones/tablets) by allowing them to access their day's transactional interests while waiting for their turn to be serviced by the counters.

Presumably they need to connect to the bank's wi-fi to do this?
Do they access the current web app through their own devices, or the bank's devices?

>> 3. We have an app server in each branch running NT webapp servicing fixed and mobile counters.

Do the customers currently access this? hence the question above...

cheers
Bruce

[de la Rosa]

>>Presumably they need to connect to the bank's wi-fi to do this? 
>>Do they access the current web app through their own devices, or the bank's devices?

1. The current web app is designed to be used by our customer to serve their customers. So it's our customer using their devices on their WiFi as of now. The intention is to expand the app to serve the transacting clients as well using their own mobile devices.

2. Intend to provide a separate wifi and router and to assign the branch app sever to uniform IP so that same mobile app/url  can be used by transacting clients in different branches.

[Bruce]

>> The intention is to expand the app to serve the transacting clients as well using their own mobile devices.

ok, this part is good.

>> Intend to provide a separate wifi and router and to assign the branch app sever to uniform IP so that same mobile app/url  can be used by transacting clients in different branches.

This is where it's going to get tricky - perhaps very tricky.

You are going to have to have a long chat to the bank IT department to figure out the best approach.

This short problem is this - HTTPS on the LAN, at the moment, has problems - not NetTalk or Clarion you understand, but regular world problems that will affect you.

Let's try and break it down;

a) Firstly using HTTP instead of HTTPS is simply not an option. If you did that, and I was simply standing outside your bank, connected to the customer wifi- I'd be able to see all customer traffic - including passwords, accounts, balances and so on.
So this road is completely closed - they REALLY do not want to do this.

b) Certificates work on the concept of chain-of-trust, but the chain of trust depends on sites having globally unique names - a side effect of the Domain system.

On a LAN you no longer have servers with globally-unique-names, and so you end up with options, but none of which are going to be good for you. This is important to hammer down now because I suspect it will lead to this whole project idea being abandoned. Simply put - it's not going to work, whatever you do. Assuming access via the internet is off the table [1] - you are going to have a very unsatisfactory customer experience.

a) The Customer will need to get the wi-fi access code, then go to their wifi settings to connect. (do'able, but clumsy)

b) presumably you need to identify the customer - so you'd need to make the wi-fi very secure from sniffing. (do'able)

c) when connecting to the server the user will see a scary warning in the browser (if it connects at all).

d) because the server has an unauthenticated name it will be subject to man-in-the-middle attacks by other customers, and would be a high security risk - too high I would suggest for a bank.

Frankly your client has a choice - allow internet access, or abandon this idea.


[1] - I'm not sure how useful a mobile app is when I have to go into the branch to do stuff anyway. Over here all our banking is online - has been for probably a decade - and I go into a branch maybe once or twice a year.


Cheers
Bruce

[de la Rosa]

Hi Bruce,

I was under the impression that when we do self-signed certificates (for LAN/IntraNet deployments), we are able to at least ensure the communication is encrypted,right? The data handled by the web app has no link to the customer db. It's more for something like filling of forms to unload the counters and those information are discarded after the transaction or being able to send notifications to the mobile devices such as to their estimated wait time,etc. While it is true the initial browser message is scary, customer IT knows they have control over the information as opposed to a mere mention of internet access. 

>>This short problem is this - HTTPS on the LAN, at the moment, has problems - not NetTalk or Clarion you understand, but regular world problems that will affect you.

Is that the reason why NT11 self-signed certificates no longer work like it used to in NT10? there are new standards? That would really be a show stopper.

Thanks,
Vic

[Bruce]

hi Vic,

>> I was under the impression that when we do self-signed certificates (for LAN/IntraNet deployments), we are able to at least ensure the communication is encrypted,right?

right.

>> The data handled by the web app has no link to the customer db. It's more for something like filling of forms to unload the counters and those information are discarded after the transaction or being able to send notifications to the mobile devices such as to their estimated wait time,etc.

ok.

>> While it is true the initial browser message is scary,

3 things here;
a) If I was in a bank and got a scary security message I would _not_ use the service. Not least because;

b) the reason you get the message is because it cannot verify that the server is the one the bank provides. Meaning a man-in the-middle attack is very possible. Even if the staff _thought_ it was ok, and told me so in the bank, it would not be safe and the _staff have no way to know if it is safe_. [As an aside, if they staff _thought_ this is ok that would seriously worry me about storing my money there - this is basic IT and they don't understand that, it makes me worry about everything else.]

c) You assume the browser will let you ignore the scary message and just proceed - whereas they may not be able to - Chrome on desktop for example is starting to not allow this, and we can expect to see this migrate to the phone as well.

>> customer IT knows they have control over the information as opposed to a mere mention of internet access.

This would scare me. The fact that the IT staff don't understand the security implications of this would worry me a lot.

>> Is that the reason why NT11 self-signed certificates no longer work like it used to in NT10?

the self-signed certs have not changed from NT10 to NT11, so if you are having problems there you need to be more specific since it's not NT.

>> there are new standards?

there are new standards all the time. Like desktop browsers not connecting to unsafe servers, even if you want them to.

In my opinion this idea is already dead.... You are solving the edge problems without addressing the massive security elephant in the room.

cheers
Bruce

[de la Rosa]

Hi Bruce,

>> c) You assume the browser will let you ignore the scary message and just proceed - whereas they may not be able to - Chrome on desktop for example is starting to not allow this, and we can expect to see this migrate to the phone as well.

Right, this is what I'm afraid of happening, it's probably still fine on a desktop where you can keep using the browser version that allows it but not on the mobile devices, which is the target of the application.


>> customer IT knows they have control over the information as opposed to a mere mention of internet access.

>>This would scare me. The fact that the IT staff don't understand the security implications of this would worry me a lot.

I understand, for this particular customer(it's not a bank) they were the ones asking for it, we only use whatever facility they provide. Btw, does the https security protocols already apply on the Socket level?


>>the self-signed certs have not changed from NT10 to NT11, so if you are having problems there you need to be more specific since it's not NT.

What I did was to follow the CIDC2017 day 2 security training on self-signed certificates in NT10 using the BasicMobile example of NT10, added the ServerSettings tab,generated self signed certificate and it worked fine. I can switch from insecure 88 to 443, had to ignore the scary message but it still allowed me to proceed with secure tag on the URL crossed out.

Then Upgraded to NT 11, Did the same thing using the BasicMobile example in NT11 this time, added the server settings, generated certificates (initially encountered cryptonite and FM3 error messages but were resolved by clearing the contents of the programdata/capesoft/nettalk/mBuild folder). It was fine in insecure port 88 but in port 443, the browser responded with ERR_REFUSED_CONNECTION and subsequently ERR_TIMED_OUT. I also noticed that after inputting port 443, within 5 secs, the log message read [insecure] listening to port 88 following [secure] listening to port 443 message.


Thanks,
Vic

[Jane]

And if you follow the Rube Goldberg approach I outline in my earlier post

• you will not get scary messages
• nobody will have to accept certificates
• you will have https connections on your internal LAN with name-matching verified by a commercial cert.
• this works on our Chromeboxes so there's no reason it shouldn't be fine on an Android or IOS device.

It does require an IT staff with a modicum of sophistication to be able to configure their internal DNS appropriately.
(We didn't invent this approach.  Our IT director dredged it out of spiceworks.  Tell that to your bank's IT to make a good impression    )

jf