Given a website that is partly public and partly an internal web application, the goal is to enable a service worker (and PWA) only for the internal routes, but not register it for the public ones.
We have:
https://example.com - Public Website
https://example.com/internal - Internal website, would like to offer as a PWA
When a user visits the public website, I do not want to register a service worker. He can then choose to log in and is then redirected to the internal web-application, which we would like to offer with PWA capabilities.
Reading the documentation (https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/register#parameters), there should be a possibility to scope the ServiceWorker to the route /internal:
navigator.serviceWorker.register('/sw.js', {scope: './internal'})
Why do I want this behavior? Because of the caching mechanisms: users visiting the public page are not coming back for a long time. If they come back after one year, they will see the old website while the Service Worker updates. On the other hand, users visiting the internal website will visit a lot more often. If they see a stale version, it will not be stale for long.
Is scoping the internal pages going to work and what are the implications?
For example, someone could choose to install a PWA, but in that case,he would be installing the internal webpage only? And what about the manifest? Should there be two manifests (public / internal) or only one for the internal page?
Related
I build an ionic app using version 1 some year ago, the app is public no authentication is required.
How can i enable api consume only from the android smartphone ?
If someone decompile the apk they can see the api and consume data from the api
How can i prevent this ?
At the end of the day, there isn't much you can do to completely prevent someone from accessing or scraping data via your public API.
However, here are some ideas that can help mitigate it:
API Key
Store an API Key in your app, and validate the key on the server side before processing the request. This suggestion isn't too helpful if they decompile your app, but at least it's a start in preventing the API from being exposed by just using the app (especially if you make all your HTTP requests over SSL).
IP Address Logging
Setup some code within your mobile app that logs the IP address of the user. Then, when a call is made to your public API - it compares the IP address from the request with the list of IP addresses that have been logged from the mobile app. You can even use timestamps to limit the time frame in which the API will be accessible.
Rate Limits/Usage Quotas
You can put some general rate-limits on your API. Only allow a certain number of requests within a specified time frame from any given IP address, user, device ID, etc.
Hope this helps. I would love to hear more thoughts from other people in the community as well!
I'm using Wildfly 10 to provide an app with 2 different servlets. One for the clients and one for the hosts.
So I have following urls:
Serveraddress/client
Serveraddress/host
Now I want to use the landing Page of Wildfly with url:
Serveraddress
as my general homepage for this app and let the users navigate to either client or host.
Is this a way to go or should I set up a usual homepage by one of the masses of webhosters.
My thought was, that I only need one server and one address to serve the web-app and the public homepage.
Are there any performance problems? Or could this be handled without any problems. As far as I understand, the landingpage is just a plain old html homepage, without any session being created.
Depends the volume of traffic. Fine for most stuff, but using nginx to serve the homepage and then proxy the other calls might be better. You can also later add caching to nginx to reduce the load on your app server or load balance against a cluster of app servers if you need to later
I want to build a Conversation Action for Google Home device and control its access. Only certain devices can invoke some actions. How can this be done, once the agent is publicly deployed?
Think of Google Home the same way you would think about a web browser and an Action the same as a web page or site. If you wanted to limit what web browsers can access a public site on the Internet, you're somewhat limited.
You could restrict access to certain IP addresses, and this will work in some cases - but it means that access via non-static IP addresses aren't possible, and if (ie - when) a machine gets a new static IP address, you have a lot of work to do. Similarly, the Google Home device can send a random user_id string for each unique user, and you can use this to limit who has access. But this string can change by the user resetting their Google Home device, and when it does, you will have to deal with that.
A better solution on the web is to allow people to log into your site. This way you can have a public facing web page, but only people with accounts can access. You can determine how to hand out accounts, so this is very flexible. The equivalent with Google Home is Account Linking where you will maintain an account as part of an OAuth2 system that you control. Google Home will ask for permission to access your system, and you will issue OAuth2 tokens to Actions - these tokens will be passed back to you for each request, and you can verify that the user has access.
I strongly suggest going with the Authorization Code Flow since this seems to be where Google is focusing on providing additional features - such as signing up to your service through Google Home.
Want to access data from external service for a facebook application. Not getting a solution on how to do the same.
Facebook apps are iframes inside Facebook. If your application has it's own server-side code, you can access that external service from the server and send the results to the client.
If you don't have your own server-side code, relying on Facebook objects for persistence, than you can access the remote service from the client via JavaScript - but there is a "but". Browsers usually only allow JavaScript to send requests to the domain where the page came from, and obviously your app is not served from the domain of the external service(otherwise it wouldn't be "external"). That means your users will have to set the security options in their browsers to allow access to remote domains - which means you'll have to supply instructions on how to do that, and we all know how good users are at following instructions... Also, having to change security options might scare away some users.
So - if possible, try to do it from your server-side.
I am trying to secure access to premium content on my app engine web application. The content is an Articulate module, it is a player.html with dozens of associated javascript, audio, and video resources. I am trying to use Google Cloud Storage to host the content.
My idea is that when a user who is authenticated with my app and has appropriate access requests the premium content, my app could sign a url to the player.html. What I am not sure about is how to handle all the associated resource files? Signed urls are simple enough for securing single files, but what about groups of files? Do I have to sign urls for all the content or is it possible to have a single signed url allow access to related files?
ACLs are not an option, because I rolled my own authentication rather than using oAuth and Google accounts.
Any thoughts or alternate strategies would be appreciated.
Update 8.7.13
After reflecting and researching some more, I am wondering about configuring the GCS bucket as a website as per the instructions here.
If I understand the docs correctly, I would create a CNAME to point requests from my custom domain content.example.com to c.storage.googleapis.com, and request that arrive via this CNAME are served up as if they were a static webpage. Does anybody know what access controls are available (if any) to files served in this manner? Would files served this way also require signing / ACLs if they are not public?
Unfortunately, your options here are somewhat limited. Below are two ideas, but both of them have fairly significant drawbacks. Neither's super great, unfortunately.
Obfuscation
Make all associated resources publicly accessible and kept under an unguessable subdirectory. The user would use a signed URL to load the secured root resource, which would include links to the publicly accessible secondary resources. Downside: the sub-resources are not secured and could be downloaded by any party that knows the URL. Possible mitigation: periodically rotate sub-resource directory.
Appengine Redirects
Change includes to route all resources through your appengine app, which would authenticate using its own scheme and redirect to a new signed URL for each subresource. Downside: lots of extra hops through appengine. So for example, player.html would include a movie as "https://yourapp.appspot.com/resources/movie.mov", which would hit your appengine app, which would in turn authenticate then redirect to the signed "https://storage.googleapis.com/yourbucket/movie.mov?signaturestuff"