how can listen to http and https requests with julia - request

I want to set up a telegram webhook and I need to receive https requests.
How can I make my ip an accessible url?
I was doing this in Python with aiohttp.

You should configure Apache web server or Nginx as a web proxy and run it with Genie.jl as a backend.
According to the Telegram webhook documentation https://core.telegram.org/bots/webhooks you need to provide an SSL server (so you will need certificate etc.). While HTTP.jl provides some SSL listen capability, almost in any integration scenario I can think of you will end up needing some options that only robust servers such as Apache or Nginx can support.
Similarly, you want to have Genie.jl as a backend of the Apache/nginx proxy (rather than HTTP.jl) - as this is a standard integration scenario for webservices in Julia and this is a higher level interface than HTTP.jl with error handling for production systems etc. You can find a detailed tutorial for Nginx setup with Genie.jl here: https://genieframework.github.io/Genie.jl/dev/tutorials/92--Deploying_Genie_Server_Apps_with_Nginx.html if you are experienced with Apache you will not have problems applying the same approach to Apache web server

Try HTTP.jl, you can start from these examples.

Related

How to do API calls with Google App Engine or Cloud Composer when the API only allows restricted IPs

I have jobs and APIs hosted on cloud composer and App Engine that works fine. However for one of my job I would need to call an API that is IP restricted.
As far as I understand, I see that there's no way to have a fixed IP for app engine and cloud composer workers and I don't know what is the best solution then.
I thought about creating a GCE with a fixed IP that would be switched on/off by the cloud composer or app engine and then the API call would be executed by the startup-script. However, it restrains this to only asynchronous tasks and it seems to add a non desired step.
I have been told that it is possible to set up a proxy but I don't know how to do it and I did not find comprehensive docs about it.
Would you have advice for this use-case ?
Thanks a lot for your help
It's probably out of scope to you, but you could whitelist the whole range of app engine ip by performing a lookup on _cloud-netblocks.googleusercontent.com
In this case you are whitelisting any app engine applications, so be sure this api has another kind of authorization and good security. More info on the App Engine KB.
What I would do is install or implement some kind of API proxy on GCE. It's a bummer to have a VM on 24/7 for this kind of task so you could also use an autoscaler to scale to 0 (not sure about this one).
As you have mentioned: you can set up a TCP or UDP proxy in GCE as a relay, and then send requests to the relay (which then forwards those requests to the IP-restricted host).
However, that might be somewhat brittle in some cases (and introduces a single point of failure). Therefore, another option you could consider is creating a private IP Cloud Composer environment, and then using Cloud NAT for public IP connectivity. That way, all requests from Airflow within Composer will look like they are originating from the IP address of the NAT gateway.

App Engine flexible behind a CDN (Fastly)

We are running an App Engine Flexible app behind with Fastly (CDN) on the front. We have set up ghs.googlehosted.com as the origin server, so the CDN forwards the request to that server if it doesn't have the cached version. This has been running fine for months.
However, we want now to ensure Fastly connects to the origin (ghs.googlehosted.com) over TLS. It seems ghs.googlehosted.com does not support TLS. Any ideas of how to overcome this situation?
So far, this is what we have found out when choosing the origin host of our CDN (Fastly):
myapp.appspot.com: Supports TLS but requires the Host HTTP header to be exactly myapp.appspot.com. Therefore, the Host header needs to be overridden.
ghs.googlehosted.com: Does not support TLS, but accepts any Host HTTP header, so you can use any of your App Engine custom domains.
More info in this thread in the App Engine group.
Edit: I was missing sending the SNI in the request. Now it works well with ghs.googlehosted.com and TLS.

How can I send cross site PUT requests through GWT?

I am creating a web application using GAE/GWT. Front end GUI is a web client and the server is a RESTFUL server both running in GAE in different domains.
I am using json with padding to communicate with the server but discovered I won't be able to send a PUT/POST/DELETE request.
My application will be used to mainly used to query data (query: 85% of cases, modify data: 15%). All requests will be authenticated.
I am considering the following options.
1) For querying use JsonpRequestBuilder, for modifying create a proxy in the web client server side and hit the REST service through this proxy. Use GWT RPC to communicate to this proxy.
2) Make every request as a GET request in my REST service (including those that modify data) and use jsonp directly from web client.
I would prefer option 1) but option 2) seems less work to do.
Should 1) be my preferred option ?
Are there any problems with 2) given all my requests will be authenticated. ?
Is there any other easy approach to solve this problem ?
Regards,
Sathya
The simplest solution is to use CORS which allows you to send requests two different origins. But it is not so widely spread (check caniuse), so if you have to support IE8-9, it will not be enough for you.
In your case I would try to implement dual solution (e.g. CORS + server proxy). If browser supports CORS - send the request directly to the target server, if it doesn't - send request via proxy.
Sorry to ask but what is the advantage to have your client running on a different domain ? From what I understand your client's server will do nothing ...
If you are not the "owner" of the REST backend, maybe this backend should developp an authorization system for third party applications, like oauth2.
Then your application can talk backend to backend with a secured connection. You can use scribe to do that on your backend.

How to build an TCP listener or server on google appengine maybe in golang?

I'd like to build an TCP receiver/listener/server to run on Google App-Engine. For example to receive messages over TCP on a specific port, similar to a syslog server, and process the request. Something in Go language would be ideal, but really anything appengine supports.
Does anyone know if and how I can setup appengine to proccess TCP requests?
AppEngine runs your applications in a sandboxed environment and you may not open sockets, as mentioned in their What Is Google App Engine? guide:
As with the Java and Python environments, not all the standard
library's functionality is available inside the sandbox. For example,
attempts to open a socket or write to a file will return an os.EINVAL
error.
App Engine's designed to handle HTTP requests, which are TCP requests. If you choose to use App Engine, you should probably design your server to handle HTTP requests.
If you need to run on a lower level, you're probably better off using something like Amazon which has tools like their elastic IPs that would make this much easier.

What are typical server to client communication patterns?

What are the usual patterns for bidirectional communication between a client and a server in a wlan environment. How is it possible for the server to push data to a mobile client over wlan after a connection has been established.
Lets say I have a webservice running on a server and the moblie cients in the wlan can use this webservice. Now the question is how can the server invoke methods at the client, or directly send data to the client. How is this handled usually?
I would apriciate some links to read about this topic.
Is this a common problem or is it not that easy to solve?
Cheers
HTTP server push (also known as HTTP streaming) is a mechanism for sending data from a web server to a web browser. HTTP server push can be achieved through several mechanisms.
More at http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push
In web development, Comet is a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term for multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins.
More at http://en.wikipedia.org/wiki/Comet_(programming)
Also there is a recent IETF draft on
Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
https://datatracker.ietf.org/doc/html/draft-loreto-http-bidirectional-01

Resources