On Tue, Jul 8, 2014 at 7:18 AM, James P <testdevp...@gmail.com> wrote:
> I have a situation where I want to make a third party request INSIDE a > current users request. > > Essentially I want to alter the traditional oauth2 flow where the user is > redirected back to the Application after authorizing their credentials for > the first time. I would like the Application to receive the authorization > code once the user approves it via an internal Request inside Django. But I > want to redirect the user to stay within my site for some additional > account process wizards. > > This is a situation where oath is being used to authorize a third part iOS > or Android application, not a browser app so I essentially don't care if > the user is redirected to the Application's own post-authorization splash > page. > I'm not 100% certain I'm following what you're trying to do, but here's an attempt at explaining what is possible. You user is going to make a request for a specific URL. The server needs to process this response, and give back a response which represents the content of that URL. This is the basic HTTP contract, and it can't be altered. Any plans you have for manipulating the oAuth2 flow must stay within this basic contract. However - what constitutes "content" of the URL is entirely up to your server, and the manner in which that "content" is generated is entirely up to you. It can be a static file on disc, a rendered template using data from a database, a random number generator, or, if need be, the result of a HTTP request that has gone off somewhere else. So - for example - a user requests yourserver.com/example_page/. When it receives that request, your server issues a request to otherserver.com/magic_page, gathers the response, and returns it verbatim to your original user. You user will then see the content of otherserver.com/magic_page at the URL yourserver.com/example_page/. Although the *content* looks like otherserver.com, it will be presented at a yourserver.com URL. If retrieving otherserver.com/magic_page requires some interaction from the original user (e.g., logging in), you can't just "get the original user to push buttons on the remote site" - any requests will need to be proxied through your own server. So, if otherserver.com requires a login, the process will be: * User requests yourserver.com/example_page * Your server requests otherserver.com/magic_page, and determines that your user is not logged in * You return content to the original user that is a form requesting login details. This might just be the login page provided by otherserver.com * The user submits their login details *TO YOURSERVER.COM/EXAMPLE_PAGE* * Your server takes those details, and submits them on the user's behalf to otherserver.com/magic_page * You get a response from otherserver.com, which you pass back down to the original user. The important thing to note here is that *you are receiving and using the user's credentials for a third party site*. The user isn't logging to otherserver - *You* are logging into otherserver, on the user's behalf. That means you've just encouraged a user to provide their password to a third party site, which is a *really* bad idea. Think *very* hard before you put a system like this into production. I hope this helps. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJxq84-PZpwX5GSz-ykEfM6SXzGCwTRNSgd6aT%2B6vOHpaU_ygA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
