Project

General

Profile

Feature #8577

Standardise DNS webservice to XEP-0156

Added by Wojciech Kapcia TigaseTeam 2 months ago. Updated 3 days ago.

Status:
Feedback
Priority:
Normal
Start date:
Due date:
% Done:

100%

Estimated time:
Source Code Disclaimer:

Description

We currently have DNS Webservice to provide information about alternative connection methods. There is a dedicated XEP for this use-case (
XEP-0156: Discovering Alternative XMPP Connection Methods ) and we should either adapt DNS webservice to it.

Associated revisions

Revision c7b432c9 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam 25 days ago

#8577: added support for XEP-0156 to DNS-WebService module

Revision f585f1a4 (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam 25 days ago

#8577: bumped dependency on HTTP API to 2.1.0-SNAPSHOT

Revision 7e0773d3 (diff)
Added by W Administrator 25 days ago

#8577 fix licence headers

History

#2 Updated by Wojciech Kapcia TigaseTeam about 2 months ago

  • Assignee set to Andrzej Wójcik

#3 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam 25 days ago

  • Status changed from New to In QA
  • Assignee changed from Andrzej Wójcik to Wojciech Kapcia
  • % Done changed from 0 to 100

I've added this feature, checked that it works and added information about it to the project documentation.

#4 Updated by Wojciech Kapcia TigaseTeam 4 days ago

  • Status changed from In QA to Feedback
  • Assignee changed from Wojciech Kapcia to Andrzej Wójcik

Deployed and configured nginx however result is a bit baffling, i.e. https://tigase.im/.well-known/host-meta gives:

<?xml version='1.0' encoding='utf-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'><Link rel="urn:xmpp:alt-connections:xbosh" href="http://localhost:5280/bosh" /></XRD>

It do seems to work for direct call (http://ec2-54-190-5-228.us-west-2.compute.amazonaws.com:8080/dns-webservice/.well-known/host-meta):

<?xml version='1.0' encoding='utf-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'><Link rel="urn:xmpp:alt-connections:xbosh" href="http://ip-10-0-37-90.us-west-2.compute.internal:5280/bosh" /></XRD>

Which would suggest something odd with proxying or handling proxy request -- possibly detecting X-Forwarded-For?

nginx confing seems ok (we could add it to documentation - what do you think?):

    location  /.well-known/ {
        if ($http_x_forwarded_proto = 'http') {
                return 301 https://$host$request_uri;
        }
        proxy_pass http://localhost:8080/dns-webservice/.well-known/;
    }

Btw. why urn:xmpp:alt-connections:websocket is not included?

#5 Updated by Wojciech Kapcia TigaseTeam 4 days ago

Also - we should use external IPs/hostnames instead of internal.

#6 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam 3 days ago

%wojtek The only issue here is the missing support for X-Forwarded-For as current implementation ignores that header and users Host header which may differ.

As for only returning BOSH, it is OK as for domain which you checked (hostname of EC2 instance) there are no TXT records and its name is resolved to the internal address and resolved back to an internal DNS name. It works just fine for domain names with TXT records.

#7 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam 3 days ago

  • Assignee changed from Andrzej Wójcik to Wojciech Kapcia

Would it be possible to add proxy_set_header Host $host to NGINX config file? as I think that is the missing part which would solve the issue and not missing support for X-Forwarded-For.

Also available in: Atom PDF