Cannot log in with IP address of pod

For experiment purposes, I am setting up different web services inside VM, and this includes a Diaspora pod. However I only use IP address to access theses services (even though I also have a local DNS server in another VM, with a correct DNS record for the pod).

Now your module sure came in handy to test the pod programmatically, however Diaspy seems incapable to log in to the pod when I pass it the IP address. Everything is fine if I give it the DNS name, and Firefox does not complain for anything, either using the IP address or the DNS name.

The pod is served by a reverse proxy by Apache (configuration closely similar to this). As you can see, there is some URL rewriting in the process, and it seems to be the cause of Diaspy dysfunction. Indeed, when I changed the rewriting part to use the IP address instead of the DNS name, it worked.

By the way, I can tell it works by querying the stream, because creating a connection and logging in reports no error (and even produces the auth token), but when I try to get the stream I get:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/site-packages/diaspy/streams.py", line 34, in __init__
    if fetch: self.fill()
  File "/usr/lib/python3.5/site-packages/diaspy/streams.py", line 131, in fill
    self._stream = self._obtain()
  File "/usr/lib/python3.5/site-packages/diaspy/streams.py", line 67, in _obtain
    raise errors.StreamError('wrong status code: {0}'.format(request.status_code))
diaspy.errors.StreamError: wrong status code: 401

The title says that it cannot log using IP address, but to be fair the real problem is that Diaspy cannot seem to handle URL rewriting properly. When it rewrites to the IP address, using the DNS name fails (but works in Firefox); and when it rewrites to the DNS name, using the IP address fails (but works in Firefox).

The logs from Diaspora show some things (file "eye_processes_stderr.log"), but it is not really significant for me. This is a working scenario (from connection creation to stream request):

// Connection creation 192.168.1.3 - - [06/Jul/2016:14:54:50 +0200] "GET /unauthenticated HTTP/1.1" 302 - 0.0076 192.168.1.3 - - [06/Jul/2016:14:54:50 +0200] "GET /users/sign_in HTTP/1.1" 200 - 0.0357 192.168.1.3 - - [06/Jul/2016:14:54:50 +0200] "GET /unauthenticated HTTP/1.1" 302 - 0.0064 192.168.1.3 - - [06/Jul/2016:14:54:50 +0200] "GET /users/sign_in HTTP/1.1" 200 - 0.1053 // Login request 192.168.1.3 - - [06/Jul/2016:14:54:55 +0200] "POST /users/sign_in HTTP/1.1" 302 - 0.2553 192.168.1.3 - - [06/Jul/2016:14:54:55 +0200] "GET /stream HTTP/1.1" 200 - 0.0717 // Stream request 192.168.1.3 - - [06/Jul/2016:14:54:59 +0200] "GET /stream.json HTTP/1.1" 200 - 0.0783 192.168.1.3 - - [06/Jul/2016:14:54:59 +0200] "GET /posts <blabla post ID> HTTP/1.1" 200 - 0.0240

And a failing scenario:

// Connection creation 192.168.1.3 - - [06/Jul/2016:14:57:25 +0200] "GET /unauthenticated HTTP/1.1" 302 - 0.0196 192.168.1.3 - - [06/Jul/2016:14:57:25 +0200] "GET /users/sign_in HTTP/1.1" 200 - 0.0340 192.168.1.3 - - [06/Jul/2016:14:57:25 +0200] "GET /unauthenticated HTTP/1.1" 302 - 0.0060 192.168.1.3 - - [06/Jul/2016:14:57:26 +0200] "GET /users/sign_in HTTP/1.1" 200 - 0.0306 // Login request 192.168.1.3 - - [06/Jul/2016:14:57:28 +0200] "GET /unauthenticated HTTP/1.1" 302 - 0.0084 192.168.1.3 - - [06/Jul/2016:14:57:28 +0200] "GET /users/sign_in HTTP/1.1" 200 - 0.0539 // Stream request 192.168.1.3 - - [06/Jul/2016:14:57:31 +0200] "GET /unauthenticated HTTP/1.1" 401 - 0.0081

Diaspy relies on Requests so it might be related to this module instead maybe? Plus there is the fact that something fails while logging in, but it replies with an "OK" code...

I know it stems from an unusual need but it is very strange that it fails for such a reason.

(...) but it is very strange that it fails for such a reason.

Well, it is, indeed. I'll see what I can do about it, but you'll have to wait until Saturday (most probably) for me to have some time to look at this problem. If you, by any chance, happen fix the error yourself, pull requests are most welcome!

I didn't fix it sadly, I just changed the URL rewriting to rewrite to the IP address. I'm not sure what should be done to manage this in Diaspy. It is very strange that there is no difference when establishing the connection, but the only difference appears when logging in: the requests as seen by the Diaspora web app are different somehow. Again, this is why I'm not sure this is really related to Diaspy, and may come from Requests, or Diaspora itself.

Guessing: maybe the pod sees that the request is directed to 1.2.3.4 instead of pod.example.com and checks against a list of allowed host values on which the 1.2.3.4 is not present, thus erroring out?