I have implemented web push using Firebase using Service-workers (which works only for https website). I want to use web push notification for http website.
I have read that it is possible to implement the web push for http website using some tweaks like subscribing to any third party.
Two questions I want to ask:
a) Is it possible to achieve the same without using any third party library?
b) How can I achieve the same behaviour for my website?
Any help is appreciated.
a) Is it possible to achieve the same without using any third party library?
From the developer guide: No, During development you'll be able to use service worker through localhost. but to deploy it you need HTTPS, the site registering the service worker must on on HTTPS and the service worker, which has to be on the same origin, will be served over HTTPS as a result. For security reasons. Having modified network requests, wide open to man in the middle attacks would be really bad
b) if you need web push notifications and you don't have an SSL take a look at Pushpad Express https://pushpad.xyz/
Related
I am hoping this is not too off topic for a post here.
I have an asp.net webAPI service, which provides a number of routes to get near realtime data (ie within say 10 seconds), which required the client application to poll for changes.
I am investigating on which technology would be best to add an "opt in" push notification service, which just pushes "thin" payloads to tell the client application it is now time to call the existing REST route for an update. This way, the push payload is small, and does not contain any security sensitive data (it still gets this using the existing REST security infrastructure)
Cloud based messaging
Previously, I have been told that, for a Mobile application, I should use something like Firebase cloud messaging, or some other messaging service, however this does not seem like the right solution for "subscription based notifications" I am talking about here. I can certainly see this would be useful, if the client is on either iOS or Android device, and wanted messages/notifications/alarms (etc), which could also work when the application is not running, but this does not seem like the right thing to use of these notifications of changed data (which may be happening all the time, sometimes every 5 seconds). Also, I do not want to only target these mobile devices, but also, for example either a web or desktop application, which may also use the same REST service
Other technologies
I have seen mention of Web sockets, or, in the case of asp.net, the option to use SignalR (which will wrap the web sockets, with fallback). SignalR looks good, but my worry is the availability of client libraries for non web / Windows applications (eg iOS, Android). I am also looking at Rest Hooks. These look interesting, but I can't quite see what the actual "push mechanism" is; it almost looks like they need to POST to the subscriber using HTTP, which means the subscriber has to also act as a "server endpoint".
Just after any thoughts / best practices on this, or what others have used?
In particular, (the verification or otherwise), that for this use case, using cloud based messaging is not the right thing to use due to the frequency of these push notifications (ie something where my server gets to the application via another 3rd party service which pushes to the device/application)
Thanks in advance for any suggestions!
Signalr is an option
There are some libraries which you can use in iOS and android. I suggest you to read once https://visualstudiomagazine.com/articles/2013/11/01/how-to-use-signalr-in-ios-and-android-apps.aspx (its a bit older, but on the point)
Android Client: See How to use signalr in Android
Some alternatives :
Pusher (https://pusher.com/)
Android Client: https://pusher.com/docs/android_quick_start
iOS Client: https://pusher.com/docs/ios_quick_start
Socket.IO (https://socket.io/)
Details iOS Client: https://socket.io/blog/socket-io-on-ios/
Details Andriod Client: https://github.com/socketio/socket.io-client-java
To discuss:
Why you will only send a thin payload whith signalr? I see no benefit for that.
Why "using cloud based messaging is not the right thing"? I do not understand your arguments but I do not know how your application looks like.
I realize a similar question has been asked here. Although it talks specifically of a custom domain, whereas i would want to send the data from the clients to the webserver where the serverside SDK is running and then send it from there. Is there any way to do this? We have PCs which will be stripped of direct internet access, however the webserver will not.
I think the answer from #John Gardner applies here - you need:
1. Send data from your app to your server/web server
2. In web server send data to Application Insights
Our system is build using microservices, that all sit behind an API gateway. Since all of them are REST API services, the benefits and whole point of using API gateway is clear to me. Now what about frontend microservices - the small components, that have both UI and corresponding backend to handle internal communication? Are there any scenarios where proxying every microservice HTTP calls is harmful?
Example
One of our microservice is a payment provider integration. As dealing with payments have specific regulations, one of those is a required web browser redirect to the user's bank page for authorization. Since this is impossible to do in a purely backend way, we deliver a frontend microservice - a service that essentially serves a HTML you must nest inside an iframe and should be able to process the payment in an e2e way. Very simplified and stripped example below.
Let's say you are on https://acme.com/order and want to pay, where such snippet is embedded:
<iframe src="https://pay.acme.com?amount=42+USD
&returnUrl=https://acme.com/thankyou/[orderId]">
</iframe>
Basically a fire and forget thing for the developers of https://acme.com. What happens inside an iframe stays there. https://pay.acme.com however now worries about: collecting credit card details, validating them, redirecting user to the bank page to enter 2FA code or whatever needed, waiting until the payment is approved and finally moving user back to the returnUrl with a proper trail for which order the payment was finalized (orderId).
Now, what about pay.acme.com frontend <-> pay.acme.com backend communication? Would it be OK to let microservice talk to itself, or rather all, even the internal communication that doesn't make any sense for API consumers, must go through the API gateway? That is of course possible to do and still keep the microservice decoupled and unaware of the API gateway, but this is much more costful than deviating from the always do constraint and bring very small benefits, as we don't use any advanced rate limiting or proxying features for now.
There is simple approach - To have UI gateway. Gateway that instead of API calls will route and proxy asset request calls (static files serving).
If entities belong to the same bounded context (pay.acme.com frontend <-> pay.acme.com backend) they should definitely exist as single backend microservice that serves one of:
isomorphic js
thin client apps with real-time reload (then UI gateway will need to proxy ws connection)
thick client app (SPA)
Such microservice is regular microservice which API (if exists) should be accessible through API gateway, and UI should be proxied via UI proxy/gateway.
Hope that helps.
I'm going to build my own system include asp.net web site and web api, they are host on separate site. Architect diagram like image link below.
Every time client update something. I need to notify to the others. For example if client 1 upload a photo via web, then client 3 and (mobile app) and client 4(desktop app) should get a notification.
My problem is how to tell SignalR send notify to clients in this case. Please advice.
Your diagram must be changed in order to achieve what you need.
In order for this to work all the client types must be SignalR aware. For the web application it's straightforward since the "client" code is the website code itself.
For the mobile and desktop you have an extra layer (webapi) which in this case is an obstacle.
You should define a SignalR hub and connect to it from all the clients: WebApp, MobileApp, DesktopApp.
Knowing this, you can make a WebAPI project containing all the API methods and the SignalR hub(s) and connect to it from the other applications, website included.
As far as I know this is the only way to make this work, as you need to include SignalR library in all the clients code and use it to communicate with the hub(s).
I've got a small ASP.NET web site, that calls another company (somewhat) Restful web service. My site has no logging currently. Is there an online service that can proxy all calls from my site and provide error logging and possibly retry functionality?
Have you tried https://ngrok.com/ - For local development, it's probably exactly what you're looking for.
If you just want to inspect the traffic your system is sending out or receiving, http://www.telerik.com/fiddler is a good choice.