This documentation page says that:
Applications in the Java 8 runtime can use native Java sockets with no restrictions
However a socket to port 25 get blocked somewhere. The code bellow works fine on my local JVM but not in Google app engine Java8 standard env.
Socket skt = new Socket("gmail.com", 25);
BufferedReader rdr = new BufferedReader(new InputStreamReader(skt.getInputStream()));
I have been going through the docs for days now, but cannot find anything explaining why its not working. Nothing on my logs neither.
Can I open a socket to port 25 on GAE or not? please help
Port 25 is always blocked for mail related security reasons.
In the Java sockets documentation that you shared is stated that:
Port 25 (SMTP) is blocked; you can still use authenticated SMTP on the submission port 587.
It's true that the documentation is somewhat misleading about if this port limitation applies only to Java 7 runtime or affects Java 8 too. I'll send feedback about this documentation page to prevent future confusion.
Related
I am not able to connect to https://test.salesforce.com/services/oauth2/token form SoapUI (ver 5.2.1). I have tried the PRO version and other older versions (4.6.xx) as well.
I can access the website from the web-browser. The GET to this URL gives me the response where as SOAPUI says HttpHostConnectException connection to https://test.salesforce.com/ refused.
I have checked that there is direct connection available from my PC to this address. I have tried adding https.proxyHost and https.proxyPort settings in soapui.vmoptions and sopaui.bat but of no use.
I have also tried playing around with Preemptive Authentication settings in SOAPUI without success
My organization has firewall which has white listed this address. I have also confirmed that firewall settings does allow to connect thru non standard clients (such as ApacheHttpClient).
If I use a Java Program using URLConnection using the proxy, it works.
At this point it seems to me that SOAPUI is not honoring the proxy settings.
Please share if anyone has similar experience and how did they resolve it.
Regards
Ash
I'm using the Managed VM functionality to run a WebSocket server that I'd like to expose to the Internet on any port (preferably port 80) through a URL like: mvm.mydomain.com
I'm not having much success yet.
Here are the relevant parts of various files I'm using to accomplish this:
Dockerfile:
EXPOSE 8080 8081
At the end of the Dockerfile, a Python app is started: it responds to health checks on port 8080 (I can verify this works) and responds to WebSocket requests on port 8081.
app.yaml:
module: mvm
version: 1
runtime: custom
vm: true
api_version: 1
network:
forwarded_ports: ["8081"]
I deploy this app to the cloud using:
$ gcloud preview app deploy .
In the cloud console, I make sure TCP ports 8080 and 8081 are accepted for incoming traffic. I also observe the IP address assigned to the GCE instance (mvm:1) is: x.y.z.z.
$ curl http://x.y.z.z:8080/_ah/health
$ curl http://mvm.my-app-id.appspot.com/_ah/health
Repond both with 200 OK.
Connecting the WebSocket server using some JavaScript works as well:
new WebSocket('ws://x.y.z.z:8081');
So far so good. Except this didn't work (timeout):
new WebSocket('ws://mvm.my-app-id.appspot.com:8081');
I'd like to know why the above WebSocket command doesn't work.
Perhaps something I don't understand in the GAE/GCE port forwarding interaction?
If this could be made to work somehow, I envision the following would be the last steps to finish it.
dispatch.yaml:
dispatch:
# Send all websocket traffic to the ManagedVM module.
- url: "mvm.mydomain.com/*"
module: mvm
I also setup the GAE custom domain CNAME at mvm.mydomain.com.
Connecting the WebSocket server using JavaScript should then work like:
new WebSocket('ws://mvm.mydomain.com:8081');
It may very well be that port forwarding from appspot.com isn't performed, given that prior to the (relatively recent) release of managed VMs, the only traffic that went to appspot.com was on port 80 or 443. I'd suggest using the IP-of-instance method you found to work.
If you don't find that fully satisfying, you should go to the public issue tracker for app engine and post a feature request to have the appspot.com router detect whether a request is heading for a module that corresponds to a managed VM and attempt the port forwarding in that case.
The thing is, putting the raw port on the end of the domain like that means that your browser will use the port you specified as a connection parameter to appspot.com, not as a query param, so appspot.com will have to listen on all ports and redirect if valid. This could be insecure/inefficient, so maybe the port number could be a query param or part of the domain string, similar to how version and module can be specified...
At any rate, given the way in which ports work, I would highly doubt, if your very simple example caused a fail, that app engine's appspot.com domain was even set up to handle port forwarding to managed VM containers at all at present.
I need to create a TCP connection in AppEngine (on the server side) and keep it alive indefinitely (or at least ~30 minutes). I've created a background thread, opened a java.net.Socket and attempted to read a line with a wrapped BufferedReader. After about 3 seconds of inactivity, I get the following exception:
java.net.SocketException: Socket operation timed out: The API call remote_socket.Receive() took too long to respond and was cancelled.
I'll include a skeleton of the code I'm using below. Any help would be greatly appreciated (including workarounds or information on the limitations of sockets in GAE). Thanks!
ThreadFactory tm = ThreadManager.backgroundThreadFactory();
thread = tm.newThread(new Runnable() {
#Override
public void run() {
Socket socket = null;
try {
socket = new Socket("localhost", 8000);
socket.setSoTimeout(0);
socket.setKeepAlive(true);
BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
writer = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));
String in = reader.readLine();
// execution never gets past here
//...
} catch (IOException e) {
e.printStackTrace();
} finally {
// ... <close socket>
}
}
});
thread.start();
In case it's relevant, here's the use case: I've got a TCP server that used to work with an embedded Applet on the client side. I'd like to redesign the Applet as a webapp, but the server still works fine, so I'd rather not change it. I'd like to write a simple servlet that keeps the TCP connection alive and feeds messages back and forth between the TCP server and the GWT client.
Sockets have lots of restrictions in GAE due to security reasons, though GAE provides many ready to use services which requires use of sockets like for email, xmpp etc.
First your app needs to be paid app, means billing must be enabled for using sockets on GAE
You can have a look here for how to use sockets in java on GAE
Below is the excerpt from google app engine documentation for socket limitations:
App Engine supports sockets without requiring you to import any
special App Engine libraries or add any special App Engine code.
However, there are certain limitations and behaviors you need to be
aware of when using sockets:
Sockets are available only for paid apps.
You cannot create a listen socket; you can only create outbound sockets.
java.net.URL is still configured to use the URL Fetch API; there is currently no way around this.
Most classes in javax.net.ssl are supported.
You can only use TCP or UDP; arbitrary protocols are not allowed.
You cannot bind to specific IP addresses or ports.
Port 25 (SMTP) is blocked; you can still use authenticated SMTP on the submission port 587.
Private, broadcast, multicast, and Google IP ranges (except those whitelisted below), are blocked:
Google Public DNS: 8.8.8.8, 8.8.4.4, 2001:4860:4860::8888, 2001:4860:4860::8844 port 53
Gmail SMTPS: smtp.gmail.com port 465 and 587
Gmail POP3S: pop.gmail.com port 995
Gmail IMAPS: imap.gmail.com port 993
Socket descriptors are associated with the App Engine app that created them and are non-transferable (cannot be used by other apps).
Sockets may be reclaimed after 2 minutes of inactivity; any socket operation keeps the socket alive for a further 2 minutes.
You cannot Select between multiple available sockets because that requires java.nio.SocketChannel which is not currently supported.)
I was recently exposed to a new authentication method i had no idea of.
After reading a bit and researching to understand it,I understood it has something to do with SPNEGO, or maybe it is just spnego.
Im running windows xp on a large network, when my browser opens it automatically
connects to a web-service in the network, which requires authentication:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Negotiate
then my browser sends automatically (along with more headers ofcourse):
Authorization: Negotiate (encrypted string).
I concluded this Handshake uses the SPNEGO protocol.
What i need to do, is to create my own client (actually,its a bot that uses this webservice that requires that authentication). I Need to get that encrypted string (exactly like my browser gets it, probably by using some SPNEGO protocol) without any user interaction (again, as my browser).
the thing is, that i don't have enough time to study the spnego protocol and how to implement one.
I'm using c/c++, but if i have no option c# would be okay as well.
Are there any functions / classes / codes or maybe even good tutorials to help me implement it shortly?
curl works with Kerberos/spnego. I'm not sure how well this functionality works on Windows, you should try and see. It works well enough on Linux. You can look at the source to see how it is done.
Is there a way to open a TCP Socket back to a non-standard Silverlight port such as port 80?
I don't quite understand the restrictions on Silverlight ports.
I would like to open a connection back to the server of origin using any port. I can serve a policy file from port 943 if needed.
Microsoft restricted the ports to a range well outside the "well known ports." This prevents Silverlight from communicating directly to most web-based resources like HTTP, POP, SMTP, etc.
The most common way to get around this is to set up a "proxy" service on your domain. The proxy accepts requests, forwards them through the port on the service you're using, and returns the result.
The allowed port range (after the policy server check) is 4502 through 4532 to my knowledge. Using port 80 would be an HttpWebRequest or the like.