There is support for running modbus/bacnet supported devices. What about https protocol?
The short answer is no, currently there is not support for https in volttron http yes, but not https. There is however an issue here https://github.com/VOLTTRON/volttron/issues/1454 to add it.
Related
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.
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.
I set up SNI/SSL on my app engine app using this excellent page.
I'd like my site to work for people still on older browsers that don't support SNI. Ideally, I'd like to detect these older browsers and redirect them to https://myapp.appspot.com.
I've seen some posts about people doing this with Apache rewrite rules, but of course you can't do that with app engine.
The ever so unhelpful GAE documentation states
We recommend detecting browsers that do not support SNI and
recommending a browser that supports it.
but doesn't give us any clue how to do that.
Any ideas how to do this?
You'll need to use SSL with Virtual IP.
The reason for this is that older browsers that don't support SNI simply don't send any indication of the server name (host) that was requested - only the IP address. Since typically Google hosts many web applications on their externally advertised and shared IP addresses there is simply no way for Google to send the request to your application in that shared scenario.
Is there a slick way to enable CORS with the Cloud Endpoints?
(Adding "Access-Control-Allow-Origin: *" or something like this to the response)
Thanks,
Brandon
As CORS works on production for Cloud Endpoints. What I did to test on devserver (local) was to disable the browser security. For Dartium (I think Chrome also) use --disable-web-security parameter on startup.
Try adding this to the yaml file of your endpoint:
x-google-endpoints:
- name: "{your-endpoint-host-name}"
allowCors: "true"
This depends on if you have control over the headers on the endpoints - either via the application or the web server serving the original page which contains scripts that want to make cross domain requests.
JSON-P still seems far more popular - either due to lack of support on the server side of platforms, or a distrust that it will work with clients (e.g. legacy web browsers) - whereas JSON-P will often work.
I have a wpf app that needs to communicate(exchange data) with a custom designed device (we can modify the code for the device). Do I have any options to connect to the device if it is behind a firewall via http? I was hoping there would be a method where the admin would not have to forward any specific ports or do anything on his end. I assume the issue is how would I address the device from my app. I know SOAP over SMTP is one option. Is another option where the device could chatter out to my application via http?
This problem is solved by relay services like Yaler or My-devices (I did not test this last one).
UPNP is supported by some firewalls to simplify this. Otherwise you are usually stuck opening ports on the firewall manually or using some 3rd party proxy server for a rendezvous server.
A lot of firewalls are setup to allow access on port 80 (HTTP) otherwise the users wouldn't be able to browse web sites on the internet. You can try and see if port 80 is open to traffic. If you can modify the code for both the device and the client you can use port 80 to communicate with your own protocol - you don't necessarily need to use HTTP.
Any kind of RESTful architecture over http will do it. If this is the best option for you depends on what APIs / libraries are available on your custom device.