2016-06-30 8 views
0

Ich versuche, eine OAUTH-Anfrage von einer anderen Anwendung an Django zu senden. Django ist auf 8000 Port gehostet und die Anwendung auf 8080. Hier ist die URL aus der Anwendung aufgerufen:fix_location_header in Django verursacht falsche Umleitung zu LOGIN_URL

http://localhost:8000/o/authorize/?client_id=MM8i27ROetg3OQv60tDcJwp7JKXi28FqkuQgetyG&response_type=token&redirect_url=http://localhost:8080/auth/add_token 

Dies wird zu einer falschen Stelle weitergeleitet:

http://192.168.56.101:8000/o/authorize/accounts/login/?next=/o/authorize/%3Fclient_id%3DMM8i27ROetg3OQv60tDcJwp7JKXi28FqkuQgetyG%26response_type%3Dtoken%26redirect_url%3Dhttp%3A//192.168.56.101%3A8080/auth/add_token 

, als ich es erwartet zu sein

http://192.168.56.101:8000/accounts/login/?next=/o/authorize/%3Fclient_id%3DMM8i27ROetg3OQv60tDcJwp7JKXi28FqkuQgetyG%26response_type%3Dtoken%26redirect_url%3Dhttp%3A//192.168.56.101%3A8080/auth/add_token 

ich habe folgende Routen in urls.py und sie: ohne das Präfix /o/authorize, die von WSGI-Handler erzeugt wird, wird unter Verwendung von HTTP-Header PATH_INFO genannt funktionieren Sie richtig, wenn es nicht für die seltsame Umleitung ist, die ich gegenüberstelle.

url(r'^o/', include('oauth2_provider.urls', namespace='oauth2_provider')), 
# OAuth User Info 
url(r'^o/api/get_userinfo/$', oauth2.GetuserInfoView.as_view(), name="get-userinfo"), 

In settings.py ich habe:

LOGIN_URL = "/accounts/login" 

hier nun die Linien von Django Code sind, die ich problematisch finden.

django/core/Handlers/base.py: 220

 # Apply response middleware, regardless of the response 
     for middleware_method in self._response_middleware: 
      response = middleware_method(request, response) 
      # Complain if the response middleware returned None (a common error). 
      if response is None: 
       raise ValueError(
        "%s.process_response didn't return an " 
        "HttpResponse object. It returned None instead." 
        % (middleware_method.__self__.__class__.__name__)) 
     response = self.apply_response_fixes(request, response) 
        # ^^^------------this will lead to fix_location_header being called. 

django/HTTP/utils.py

def fix_location_header(request, response): 
    """ 
    Ensures that we always use an absolute URI in any location header in the 
    response. This is required by RFC 2616, section 14.30. 

    Code constructing response objects is free to insert relative paths, as 
    this function converts them to absolute paths. 
    """ 
    if 'Location' in response: 
     response['Location'] = request.build_absolute_uri(response['Location']) 
    return response 

django/request.py

def build_absolute_uri(self, location=None): 
    """ 
    Builds an absolute URI from the location and the variables available in 
    this request. If no ``location`` is specified, the absolute URI is 
    built on ``request.get_full_path()``. Anyway, if the location is 
    absolute, it is simply converted to an RFC 3987 compliant URI and 
    returned and if location is relative or is scheme-relative (i.e., 
    ``//example.com/``), it is urljoined to a base URL constructed from the 
    request variables. 
    """ 
    if location is None: 
     # Make it an absolute url (but schemeless and domainless) for the 
     # edge case that the path starts with '//'. 
     location = '//%s' % self.get_full_path() 
    bits = urlsplit(location) 
    if not (bits.scheme and bits.netloc): 
     current_uri = '{scheme}://{host}{path}'.format(scheme=self.scheme, 
                 host=self.get_host(), 
                 path=self.path) 
     # ^^^---The location URL forming logic that I find problematic. 
     # Join the constructed URL with the provided location, which will 
     # allow the provided ``location`` to apply query strings to the 
     # base path as well as override the host, if it begins with // 
     location = urljoin(current_uri, location) 
    return iri_to_uri(location) 

I enthalten die Kommentare aus der Quelldatei, damit der Leser wissen kann, dass es Anwendungsfälle für sie gibt.

Also, was ist die richtige Art und Weise zu umgehen apply_reponse_fix? 1) erben und neu schreiben die Funktion 2) ändern HTTP-Header PATH_INFO ... irgendwie 3) ändern Sie die Logik für Location Header als Antwort, so dass es eine vollständige URI mit http:// Präfix ist, so dass bits.scheme ist keine. Keiner von ihnen scheint eine richtige Lösung für mich zu sein, also frage ich mich, ob ich eine Konvention übersehen habe. Jede Einsicht wird sehr hilfreich sein.

Antwort