I am developing a simple chatbot using the DialogFlow agent and using the web interface to communicate to the agent.
I want to bind it to the existing web portal which runs behind a firewall. So, my question is on which port numbers does the Dialog Flow agent communicates with so that I can open those specific ports on the firewall.
You specify this in your Fulfillment webhook call. Otherwise HTTPS defaults to 443, and http to 80.
https://yourdomainname:port/url
https://yourdomainname.com:5000/webhookpageserverurl
(will open up to port 5000)
Training
http://www.webreference.com/html/tutorial2/2.html
Related
Is it possible to build a custom SMTP server on Google App Engine to listen for incoming email, using the Python smtpd module?
App Engine's hosted and custom runtimes are meant for HTTP traffic (ports 80 and 443). You will not be able to receive traffic on the ports necessary to operate an SMTP server.
In fact, ports 25, 465 and 587 are blocked for outbound connections across all of Google Cloud. Instead, you can use an external service such as SendGrid, Mailgun, or Mailjet: https://cloud.google.com/compute/docs/tutorials/sending-mail#choosing_an_email_service_to_use
(This article is about sending email but these services allow you to receive email as well.)
I'm trying to deploy a Loopback project to live server, all works well on local. On server, after running node ., I get the console log of:
Web server listening at: http://domainname:3000
Browse your REST API at http://domainname:3000/explorer
So it looks like the server is running.
Problem is that I get no response from the server. Neither from domain:3000 or /explorer or any endpoint I created.
Does anyone know what might be the issue?
Thank you very much
I had a similar problem when I was trying to deploy my code. Some of the possible solutions to the problem depending on where and how you are deploying it-
Check if your security group allows connections on port 3000. AWS EC2 by default closes all ports except port 80. You might have to add an exception to your security group and allow port 3000 to be accessed from everywhere.
If you are using a container, check if your container has the ports open and if the container port is accessible by the hardware hosting the container. On Azure, I faced this problem as Azure Web App Container Service by default only listens to port 80 and 8080. So I had to modify my code such that it can use the default NODE_ENV.PORT or 8080.
I have two node js application. One of them is a webserver. It serves static html css javascript and image files. This web server is running on google cloud app engine. I have a domain that is bind to this app engine. And whenever a user visits my domain my webserver gives responses to it and it gets my frontend of my website.
The other node application is a socket server(socket io). It runs on a compute engine and i want this socket server to communicate securely. Because there are important messages for me in a communication of client and server sockets. Thats why i bought an ssl certificate.
I applied my ssl certificate to my domain and now i want my client sockets to connect to a port of my domain(for example to https://www.example.com:8443)
However i dont know how to forward 8443 port of my domain into my compute engine's 8443 port without terminating the https security.
How can i do that?
Thank you in advance
Well the Google Console has a networking section from where you can open ports for your applications. See this link: https://console.cloud.google.com/networking/firewalls/list?project={your-project-id}. Replace {your-project-id} with your project id.
Another option is that instead of using a ssl certificate, you can encrypt the messages sent between your server and client
I understand pretty well that Windows RDP works on TCP port 3389, I came across Remote Desktop Web Connection feature in IIS that adds tsweb access, my question is, does Remote Desktop Web Connection use http protocol as a transport protocol over port 80? Or is tsweb just an ActiveX control that acts as an rdp client and connects normally to 3389?
Windows Remote Desktop Services (RDS) role have a IIS feature called "Remote Desktop Gateway". This gateway makes the TSWeb ActiveX to tunnel the RDP session through an HTTPS channel (port 443) instead of having it acting as an RDP client (using the mstsc COM object probably) on port 3389.
If you don't mind trying an open source alternative, written in C# (.NET) and also using a IIS gateway (but not the RDS one), without any plugin browser side (and working in all browsers, HTML 4 and 5), I released recently Myrtille.
The Remote Desktop Web Access role (formerly Terminal Services Web Access) installs a website on a Windows Server machine. "TSWeb" is a website : you access it using the http protocol.
If you access this website with Internet Explorer, IE will ask you if you want to download an ActiveX. This ActiveX will allow you to connect to remote machines via port 3389 (RDP). However, "TS Web Access" itself is not an activeX, it is a website containing an activeX.
FYI, other browsers do not support activeX objects. On such browsers, the "TSweb" website will make you download a .RDP file instead of launching a remote connection via the activeX. When you double click on this file, or launch it with Remote desktop client, the remote connection is established via port 3389.
It seems like the solution to my problem should be easier than it is, which makes me think I'm missing the obvious. I'm trying to test and ensure that a remote client machine can send/receive messages from an Azure Service Bus Queue.
I'm using the sample application provided by Microsoft at https://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-amqp/
The sample application works perfectly fine as long as all ports are open. However, I need the solution to work when only ports 80/443 are available. If I configure Windows Firewall to only allow inbound/outbound traffic on 80/443 it doesn't work. I receive the error "An attempt was made to access a socket in a way forbidden by its access permissions".
The offending line from the sample application is:
sender = factory.CreateMessageSender(entityName);
I've looked at an extraordinary number of sites and one of the suggestions I've found was to set the connectivity mode to Http such as this:
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;
That doesn't work either.
I'm not trying to setup custom services on either the remote client or Azure hosted roles. I just need them to both be able to send/receive messages via Azure's Service Bus Queues and Topics.
Can anyone point out my flaw?
From my comment above...
I found the answer to why it's not working in my case. The preview library for AMQP in Azure uses a different port then all other documentation I can find. Using the release library it works over https automatically.
Http Connectivity mode doesnt work for Http 1.0. It will work only on Http 1.1...
If you are in Http 1.0 (mostly proxy) you have to open TCP ports (9350-54)