I have an application (spring boot 2.5.6) where the user is able to request a REST resource with a callback uri as query parameter eg. https://someservice/callback or http://localhost:5555/callback. This works well if a user specifies a port which is not equal to the internal tomcat port (8080 in this case). However if the user defines an uri like http://localhost:8080 he's not redirected to http://localhost:8080/callback but to the uri which was specified in the request Host-Header eg. https://myservice.com/callback:
Working as expected
GET https://myservice.com/foobar?callback=https://someotherservice/callback HTTP/1.1
Host: myservice.com
...
HTTP/1.1 303
Location: https://someotherservice/callback?...
...
Working as expected
GET https://myservice.com/foobar?callback=http://localhost:5555/callback HTTP/1.1
Host: myservice.com
...
HTTP/1.1 303
Location: http://localhost:5555/callback?...
...
Not working as expected
GET https://myservice.com/foobar?callback=http://localhost:8080/callback HTTP/1.1
Host: myservice.com
...
HTTP/1.1 303
Location: https://myservice.com/callback?...
...
I'm not able to reproduce this behavior on my local machine (windows 10). This happens on our dev environment (debian buster). Any ideas who is rewriting the url (spring, tomcat?) and how I'm able to prevent this behavior? I tested it on a single instance to be sure it's not our loadbalancer.
Thank you in advance!
Related
I need to fetch some data from a biometric device connected to the customer's PC and return it back to my production server. I'm using a Mantra MFS100 Biometric Device to capture biometric data of the user. According to Mantra's document the biometric service will be running in 127.0.0.1. I'm able to utilize different endpoints and fetch the data required locally(using pycharm IDE windows) but when trying from my production Ubuntu Server it does not work.
The biometric service will be running on port range 11100 - 11120. To use the service I need to discover the port on which the service is running.
Code to discover the service:
import requests
for port in xrange(11100, 11122, 1):
response = requests.request('RDSERVICE', 'http://localhost:%s' % str(port), headers=headers, data=data)
if response.status == "READY":
device_port = port
if port == 11121:
print "Fingerprint device is not connected"
If the service is READY, I can move on to capture the device data:
import requests
response = requests.request('CAPTURE', 'http://localhost:%s/rd/capture' % device_port, headers=headers, data=data)
print response.text
This works when I'm trying from Local Windows IDE and endpoint as Localhost or 127.0.0.1 but does not work when I try from Ubuntu Server. When trying from the Ubuntu Server I get the following error:
HTTPConnectionPool(host='127.0.1.1', port=11100): Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f677d12cf10>: Failed to establish a new connection: [Errno 111] Connection refused',))
I also tried passing the user's ip as the endpoint to no avail:
import requests
import socket
ip_address = socket.gethostbyname(socket.gethostname())
response = requests.request('CAPTURE', 'http://%s:%s/rd/capture' % (ip_address, device_port), headers=headers, data=data)
How can I access Window's Localhost from Ubuntu Server(NGINX) in Python?
Edit:
This is the request, response data from the document:
Request:
RDSERVICE * HTTP/1.1
HOST: http://127.0.0.1:[port]
EXT: APP_NAME
Response:
HTTP/1.1 200 OK
CACHE-CONTROL:no-cache
LOCATION:http://127.0.0.1:<rd_service_port>
Content-Length: length in bytes of the body
Content-Type: text/xml
Connection: Closed
<RDService status="READY|USED|NOTREADY|..." info="provider info for display purposes">
<Interface id="CAPTURE" path="/rd/capture" />
<Interface id="DEVICEINFO" path="/rd/info" />
</RDService>
I solved this by executing the logic as ir.actions.client action with Javascript instead of Python. I'm able to access Localhost when I execute the logic as a client action.
I want to connect relay to sentry.io via proxy service/application.
Please help me in this I am not able to find any way to put proxy between relay and sentry.
Config.yml
relay:
mode: managed
upstream: “https://sentry.io/”
host: 0.0.0.0
port: 3000
tls_port: ~
tls_identity_path: ~
tls_identity_password: ~
Where I have to set the proxy in relay?
You can replace the upstream location to your proxy service/application and there you need to have another relay which can upload the data to sentry.io
Warn : This will just forward the messages, so configure your first relay in proxy mode.
We have Spring Boot service running in Kubernetes.
This service has endpoint:
- GET /healthz
We have liveness probe that uses this endpoint. Probe runs successfully.
It means that the endpoint is reachable from the service pod (localhost).
When I run in the service pod :
wget https://localhost:8080/healthz
I get an answer (OK)
When I try to call this endpoint outside the pod wget https://myhost:8080/healthz, I get response 400 without body.
I don't see any logs of Sprint. It seems that it does not reach the Sprint .
When I added flag -Djavax.net.debug=all I see in log that TLS handshake finished and then:
GET /healthz HTTP/1.1
host: myhost:8080
accept: application/json
Connection: close
and immediately
HTTP/1.1 400
Transfer-Encoding: chunked
Date: Mon, 25 Jun 201 8 08:43:43 GMT
Connection: close
When I try wget https://myhost:8080/blahblah (non existing endpoint),
I still get 400, not 404!
When I try wget https://myWronghost:8080/healthz (wrong host), I get an error Bad address. It means that host 'myhost' is correct (otherwise I would get this error).
Docker file:
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE
COPY ${JAR_FILE} app.jar
ENV JAVA_TOOL_OPTIONS -Dfile.encoding=UTF8
ENTRYPOINT ["java","-Djavax.net.debug=all", "-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]
EXPOSE 8080
Summing up:
The service endpoints are accessible from within service pod, but not accessible from outside the pod.
Any idea why?
Update:
The problem was solved by calling the service with fully qualified domain name : serviceName.namespaceName.svc.cluster.local
Tomcat didn't accept calls with short domain serviceName.namespaceName, it responded 400.
Your issue can be caused by https://github.com/spring-projects/spring-boot/issues/13205.
All you have to do is upgrade Tomcat version to 8.5.32. You can do that by adding the version in pom.xml file.
<properties>
<!-- your properties -->
<tomcat.version>8.5.32</tomcat.version>
</properties>
If you are using Spring boot 2 this may be due to bug in Tomcat 8.5.31 that doesnt allow '-' in last part of FQDN
Update Tomcat to 8.5.32 fixes this.
Reference:
https://github.com/spring-projects/spring-boot/issues/13205
https://bz.apache.org/bugzilla/show_bug.cgi?id=62383
https://bz.apache.org/bugzilla/show_bug.cgi?id=62371
Not sure if it has any influence here, but you're trying everything with https. Can you try with http instead? Your spring app probably doesn't support https on port 8080.
The problem was solved by calling the service with fully qualified domain name :
service-name.namespace-name.svc.cluster.local
The service didn't accept calls with service-name.namespace-name, responded 400.
This image is ProxyDroid application and I saw some proxy soft wares like these one.
I find some free servers for http method (http proxy the famous one) and find servers for socks 4 and 5 but I cant find any server that support https and http tunnel and in other word I cant understand what are exactly these protocols.
Proxying HTTPS is done with a HTTP proxy by using the CONNECT request. Using this request the HTTP proxy is instructed to create a tunnel to the target server. Inside this tunnel the client can the do the TLS handshake needed for HTTPS:
> CONNECT example.org:443 HTTP/1.0
>
... proxy established TCP connection to example.org:443 ...
< HTTP/1.0 200 Connection established
<
... tunnel to target established
... proxy forwards data between client and target unchanged
<-> TLS handshake
<-> application data protected by TLS
HTTP tunnel is similar. Normally a HTTP request gets proxied by sending a HTTP proxy request:
> GET http://example.org/index.html HTTP/1.0
> Host: example.org
>
... proxy connects to target example.org and forwards request
... then sends response from target server back
< HTTP/1.0 200 ok
< Content-length: ...
< ...
With HTTP tunnel the client instead uses the CONNECT method described above to create a tunnel to the target server and send the request:
> CONNECT example.org:80 HTTP/1.0
>
< HTTP/1.0 200 Connection established
<
... tunnel established, send HTTP request over tunnel and get reply back
> GET /index.html HTTP/1.0
> Host: example.org
> ...
< HTTP/1.0 200 ok
< ...
I am testing an API I have made using Springboot from my laptop (192.168.1.217:8080) and I am trying to get a cURL request via SSH from my Raspberry Pi.
Here is the error I am receiving when I try to send the request via port 8080 which it seems to not like:
pi#raspberrypi:~ $ curl -v 192.168.1.217:8080/api
* Hostname was NOT found in DNS cache
* Trying 192.168.1.217...
However cURL does work for the same IP but with port 80:
pi#raspberrypi:~ $ curl -v 192.168.1.217
* Rebuilt URL to: 192.168.1.217/
* Hostname was NOT found in DNS cache
* Trying 192.168.1.217...
* Connected to 192.168.1.217 (192.168.1.217) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: 192.168.1.217
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Thu, 30 Mar 2017 17:20:43 GMT
* Server Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.5.38 is not blacklisted
< Server: Apache/2.4.23 (Win32) OpenSSL/1.0.2h PHP/5.5.38
< X-Powered-By: PHP/5.5.38
< Location: http://192.168.1.217/dashboard/
< Content-Length: 0
< Content-Type: text/html
<
* Connection #0 to host 192.168.1.217 left intact
pi#raspberrypi:~ $
I've tried looking around but to no avail... anybody have any suggestions as to why I cannot find my own hostname in the DNS cache?
Cheers
No, Hostname was NOT found in DNS cache is not the problem. You can clearly see on the next line, in both examples, that after saying that curl is trying to connect to 192.168.1.217. Your problem is that nothing is answering on port 8080 on that IP address (while an Apache server is answering on port 80 there).
If you're getting a long pause and then a timeout rather than a quick "Connection refused", you almost certainly need to open port 8080 in the local firewall on your server machine.
curl without a protocol prefix presumes HTTP port 80.
To use another port, where it does not make that assumption, all you need to do is change your command's URL to be like this:
curl -v http://192.168.1.217:8080/api
Here is a decent article on the subject: Using CURL For Testing Web Applications