We´re transforming a SAP Fiori launchpad into a PWA by loading a manifest and a service worker from a custom endpoint. The actual server (SAP Gateway) is composed of multiple clients (~tenants) and we use a web dispatcher (reverse proxy) that allows users to access client specific launchpads by mapping HTTPS ports to gateway clients. Applications vary between clients.
Goal: Provide separate PWA installations for each gateway client.
Issue: Chrome on Android ignores the port when checking whether a PWA for the current page is already installed (same origin-domain).
Example:
Instance
Client
Host
Page URL
DEV
100
dev.company.com:11443
/sap/bc/.../FioriLaunchpad.html
DEV
200
dev.company.com:21443
/sap/bc/.../FioriLaunchpad.html
Lets say we install the launchpad PWA for dev.company.com:11443 (client 100) and then access the dev.company.com:21443 (client 200) launchpad using Chrome on Android. Chrome considers that page to be installed as there is a PWA registered for dev.company.com:/sap/bc/.../FioriLaunchpad.html although the port and therefore the origin of the client 200 page differs. Thus, there is no way to install a separate PWA for client 200.
From my understanding PWAs should be (somehow) origin dependent. What am I missing? Is there any way to enforce some kind of same-origin behavior? This works fine using Chrome on Windows btw.
Related
We are doing some server set up.
We are using a Api gateway(Ocelot) installed on the server Y which will connect to Apis hosted on server X.
Server X also has a react application.
Server Y is accessible over Internet where as server X is accessible from server Y.
Now the Apis are working perfectly but the react application is not opening through the ocelot ( server Y).
So question is will ocelot open react application?
Are you deploying the ocelot api gateway in a DMZ and the react-app and web services, database behind the firewall and allow only specific access via browser, mobile.
is this a pwa site, then you should be careful about using ocelot for something that is not intended for. ocelot is an api gateway tool/technology and not unlike nginx that can perform this additional activity of routing the calls to web application and web services.
please check the documentation of ocelot api gateway, if it allows for web application routing as well.
I have an internal WEB application I use, with a local printer attached.
To control the local printer (it's a ticketing printer) I use locally a small program that manages it. In order for my WEB application to "use" the printer, I make it to POST AJAX request to the small local program.
My WEB application is served with HTTPS, while the local program exposes a simple HTTP API through HTTP (non-secure).
The problem is, I am facing blocked: mixed-content restrictions when accessing the application through HTTPS (in development mode I wasn't seen this, of course).
I have several fixes (don't like any of them):
Make the local program to expose its simple HTTP API through HTTPS.
It's doable, but I will face problems with self signed certificates (will have to install them on the target machine), or will have to use DNS tricks to expose it under a "name".
Disallow browsers to block mixed-content
Doable. But will have to configure each browser accessing my application, plus will make them less secure.
====
So my question is: is there another way of circumventing/bypassing the blocked: mixed-content restriction? Ideally supported on new Firefox and Chrome versions.
You shouldn't but you can upgrade all non-secure requests by allowing it in your header
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
I have my Angular front-end set up to try and hit a RESTful endpoint. The Angular front-end is being served on localhost:3000, and the RESTful back-end is being hosted on localhost:8080.
In my Angular rest client service, I make the call (which I subscribe to elsewhere in my application):
getCurrentSlides(): Observable<Slide[]> {
return this.http.get("localhost:8080/app/slides")
.map(extractData)
.catch(handleError);
}
But when Angular tries to hit that URL, I get the following error:
XMLHttpRequest cannot load localhost:8080/app/slides. Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.
And yes, CORS is enabled on my server.
this.http.get("localhost:8080/app/slides")
You're missing the http:// in the URL. With that, most browsers will still require CORS for the different ports, but IE does not, so when adding http:// you should be able to test using IE:
IE Exceptions
Internet Explorer has two major exceptions when it comes to same origin policy
Trust Zones: if both domains are in highly trusted zone e.g, corporate domains, then the same origin limitations are not applied
Port: IE doesn't include port into Same Origin components, therefore http://company.com:81/index.html and http://company.com/index.html are considered from same origin and no restrictions are applied.
These exceptions are non-standard and not supported in any other browser but would be helpful if developing an app for Windows RT (or) IE based web application.
That said, you should enable CORS. (But it seems you did, so then it's just the missing http:// prefix.)
I'm using Eclipse to develop an app that consists of an Angular 2 front end and a Java REST back end.
For the front end, I'm using the Angular CLI plugin, which starts the app by issuing an ng serve command to the CLI. This command sets up an http server on port 4200.
For the back end, I'm using an in-company framework that launches in Jetty within Eclipse in port 8088.
While both these ports are configurable, by nature of the frameworks and plugins in use, they'll always be distinct.
Authentication works via an OAuth2 service that is also deployed to port 8088, as part of the framework. This service sets a cookie which certifies the browser session as authenticated. I have verified that this service works correctly by testing it against a Swagger instance of the REST API (also running in 8088 as part of the same framework).
The problem is that when the browser is aimed at the Angular 2 app on :4200, its internal REST API requests to :8088 aren't carrying the authentication cookie. Presumably, this is because of cross-site protection.
Is there any way for the app or the framework to tell the browser that these two "sites" are actually part of the same system?
Alternatively, if I have to configure the dev browser (Chrome) to work, I can live with that too. However, I've tried the --disable-web-security --user-data-dir recommendation, but the cookie still doesn't show up on the requests.
Lastly, I have Apache installed on the dev machine. If I can set up appropriate vhosts and use it as a proxy so that the browser thinks it's all the same, that would probably work too. It would just be a matter of intercepting all /swagger and /api requests and sending them to :8088, and all forwarding all other requests to :4200. However, I've been banging my head against mod_rewrite and mod_proxy and haven't been able to come up with anything that works.
I think what you're looking for is
withCredentials = true
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
I have a gadget[*] that connects to the user's WiFi network and responds to commands over a simple REST interface. The user uses a web app to control this gadget. The web app is currently served over http and the app's javascript does AJAX calls to the gadget's local IP address to control it. This scheme works well and I have no issues with it.
[*] By "gadget" I mean an actual, physical IoT device that the user buys and installs within their home, and configures to connect to their home WiFi network
Now, I want to serve this web app over https. I have no issue setting up https on the hosting side. The problem is, now the browser blocks access to the gadget (since the gadget's REST API is over http and not https).
The obvious solution is to have the gadget serve it's REST API over https. But how? It has a local IP address and no one will issue a certificate for it. (Even if they did, I'd have to buy a boatload of certificates for each possible local IP address.) I could round-trip via the cloud (by adding additional logic on my server side to accept commands from the web app and forward it to the gadget over another connection), but this will increase latencies.
Is there a way around this problem? One possibility that I have in mind is to:
Get a wildcard certificate (say, *.mydomain.com)
Run my own DNS that maps sub-domains to a local IP address following a pattern (For example, 192-168-1-123.mydomain.com would map to 192.168.1.123)
Use the wild-card certificate in all the gadgets
My web app could then make AJAX calls to https://192-168-1-123.mydomain.com instead of http://192.168.1.123 and latencies would remain unaffected aside from the initial DNS lookup
Would this work? It's an expensive experiment to try out (wildcard certificates cost ~$200) and running a DNS server seems like a lot of work. Plus I find myself under-qualified to think through the security implications.
Perhaps there's already a service out there that solves this problem?
While this is a pretty old question, it is still nothing that you find out-of-the-box solutions for today.
Just as #Jaffa-the-cake posted in a comment, you can lean on how Plex did it, which Filippo Valsorda explained in his blog:
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/
This is very similar to what you proposed yourself. You don't even need a wildcard certificate, but you can generate certificates on-the-fly using Let's Encrypt. (You can still use wildcard certificates, if you want, which Let's Encrypt supports now, too.)
Just yesterday I did a manual proof-of-concept for that workflow, that can be automated with the following steps:
Write a Web Service that can create DNS entries for individual devices dynamically and generate matching certificates via Let's Encrypt - this is pretty easy using certbot and e.g. Google Cloud DNS. I guess Azure, AWS and others have similar offerings, too. When you use certbot's DNS plugins, you don't even need to have an actual web server running on port 80/443.
On you local device, contact that Web Service to generate a unique DNS entry (e.g. ..yourdns.com) and certificate for that domain
Use that certificate in your local HTTPS server
Browse to that domain instead of your local IP
Now you will have a HTTPS connection to your local server, using a local IP, but a publicly resolved DNS entry.
The downside is that this does not work offline from arbitrary clients. And you need to think of a good security concept to create trust between the client that requests a DNS and certificate, and your web service that will generate those.
BTW, do you mind sharing what kind of gadget it is that you are building?
If all you want is to access the device APIs through the web browser, A Simple solution would be to proxy all the requests to the device through your web server.this was even self signed certs for the devices wont be a problem. Only problem though is that the server would have to be on the same network as your devices.
If you are not on the same network, you can write a simple browser plugin (chrome) to send the api request to IoT device. but then the dependency on the app/plugin will be clumsy.