I've been developing a mobile app (iOS) with gRPC via Firebase auth(z). My server is using GKE with the NGinx proxy - so now I'm developing the Web UI for the deeper configuration of a user account. I prefer not to fall back to REST API's, so I was wondering if Google Cloud Endpoints supports websockets, and would it also prevent non-authorised app users from trying to make a request? With websockets I know it's possible, but as I'm tied in with gRPC with Cloud Endpoints, I'm just checking before I fall back to REST API calls (I prefer not to!).
Summary: Does Google Cloud Endpoints support Websockets with JWT auth tokens from Firebase?
Thanks
It looks like ESP supports websockets now, using the "--enable_websocket" flag in the esp config.
Currently, Cloud Endpoints doesn't support WebSockets at all.
Btw, what is your use case for WebSockets? WebSocket won't work with gRPC either. If you just want to talk to your gRPC service from Web UI, transcoding should work. It works with JWT from Firebase auth.
The Google Cloud Endpoints ESP doesn't support websockets.
However, Google Cloud Endpoints have open sourced their Extensible Service Proxy implementation. Internally it's implemented as a custom nginx module. Since Nginx supports websockets, it should be feasible to add support to their nginx:esp module.
But it's definitely out of scope for me. :-)
Related
I have a frontend app in Fargate (ECS) in a private subnet exposed to internet through an Application Load Balancer. My frontend makes API calls to my backend apps, also in Fargate, same VPC.
Users calls to my frontend are made via HTTPS, but my frontend communicates with my backend via HTTP (AWS Service Discovery - AWS Cloud Map). This way, the user browser is showing the error "blocked: mixed content" since half of the communication is made via HTTPS and the other half uses HTTP.
infra here
As far as I know and had been searching, it is not possible to use a SSL/TLS certificate with Service Discovery.
I've made a lot of researches and couldn't find something really useful. I also tried to create an internal load balancer for each backend service but the communication is timing out, it only works when I have a VPN connected.
What am I missing here? Do I need an internal load balancer in front of each backend service to attach a certificate between frontend and backend? What is the best approach to solve this?
Users calls to my frontend are made via HTTPS, but my frontend communicates with my backend via HTTP (AWS Service Discovery - AWS Cloud Map). This way, the user browser is causing the error "blocked: mixed content" since half of the communication is made via HTTPS and the other half uses HTTP.
The user's browser wouldn't know anything about this if the communication was happening between the front-end server and the back-end server. Apparently you have front-end client JavaScript code running in the user's web browser trying to access the backend server directly.
If you want to access the backend server directly from the user's web browser, then service discovery won't work, because service discovery is only for traffic that is inside the VPC. And of course by trying to use service discovery in this way you are also causing a security issue which the browser is correctly blocking you from doing. You will need to add another load balancer, or another listener on your current load balancer, that exposes the backend API to the Internet.
Alternatively you could use a reverse proxy like Nginx on your front-end server to send backend API requests to the backend service, and then have your client-side JavaScript code send all requests to the front-end server.
We are evaluating mesibo for InApp messaging within our SaaS application. We would need OnPrem setup to comply to Data compliance requirements.
One clarity we would need on this regard is, when we switch from Cloud to Onprem setup still client side code continues to use https://mesibo.com url. In this case we believe all the traffic gets routed to our OnPrem server via Mesibo server.
Please confirm if this understanding is right? If so would there be any data residing on Mesibo server? This clarity is required for us to respond to our customers.
Thanks
No, once you enable On-premise, your client directly connects to your on-premise server. You can verify it using netstat utility. mesibo cloud will have no access to your data.
Refer to the following to learn more https://mesibo.com/documentation/faq/on-premise/#do-i-need-to-change-or-recompile-my-apps-to-run-with-mesibo-on-premise
Mesibo APIs support both cloud and on-premise. By default, it connects
to the cloud. However, if the app is configured to be on-premise, the
mesibo cloud will refuse to serve and will ask the client to connect
to an on-premise server, and will disconnect. Then onward, the client
will directly connect to the on-premise server and then all the
messages and calls will route to your mesibo on-premise server.
We are using java library com.google.cloud:google-cloud-dlp to make Google Cloud DLP calls. On the client side, we are utilizing DlpServiceClient. I know for the fact that it internally uses gRPC. Wondering whether the default communication uses SSL/TLS?
The default communication doesn’t use SSL/TLS.
Token-based authentication with Google: gRPC provides a generic mechanism (described below) to attach metadata based credentials to requests and responses. Additional support for acquiring access tokens (typically OAuth2 tokens) while accessing Google APIs through gRPC is provided for certain auth flows.
For applications running in GCE, a default service account and corresponding OAuth2 scopes can be configured during setup. At run-time, this credential handles communication with the authentication systems to obtain OAuth2 access tokens and attaches them to each outgoing RPC on the corresponding channel.
gRPC-enabled Cloud APIs generally have both REST and RPC interfaces, so rather than just using JSON over HTTP to talk to the REST interface, gRPC-enabled API clients can also use protocol buffers and gRPC over HTTP2 to talk to the RPC interface.
I currently have services running on the Google App Engine platform which use the X-Appengine-Inbound-Appid header to limit HTTP requests to our apps only.
I recently found out that some of my services require a static IP and therefor I would like to move some of the services to the Kubernetes Engine.
Is there a way for Kubernetes Engine to secure requests using a similar header approach? The requests should only be allowed from our own Firebase apps.
Ideally I would keep things as simple as possible for the clients using the services.
Possibly I could generate a specific API key for each user which can be blacklisted on abuse, but that already adds quite a bit of complexity.
You can use ngnix ingress controller as an entry point for your cluster, and add whatever rules for ngnix.
I have a web application that uses websockets to receive real time updates. Since I don't use the websocket connection for anything else, and scaling websocket servers is a pain, I'm considering moving the messaging part to Firebase Cloud Messaging.
It seems a pretty straight forward port for my web app.
However, the web app comes with a companion desktop app that some customers use, that is written in QT+Python. Is there any way to receive the FCM messages in a different client than the official SDKs?