I'm using omniauth to connect to tumblr in my app, and can't seem to
get tumblr to respect the value of oauth_callback I'm passing when I
get a request token. The request token request/response looks like:
It seems that it is common issue for now. I also can not get redirect
where i need, it only redirects to the default url, though i always
get oauth_callback_confirmed=true .
It needs some clarification from Tumblr guys.
On 22 июл, 04:20, Travis Vachon <tra...@copious.com> wrote:
> I'm using omniauth to connect to tumblr in my app, and can't seem to
> get tumblr to respect the value of oauth_callback I'm passing when I
> get a request token. The request token request/response looks like:
> Despite this, however, the response to the authorize call is always a
> redirect to the default callback url I've configured in my tumblr
> application:
> Is this a known issue? FWIW, the twitter oauth api seems do the right
> thing, and the request/response chain seems to be about the same
> otherwise.
> Thanks! Let me know if I can provide any more information.
For what it's worth, I've run into this with other APIs (FB springs to
mind, although it may be fixed now).
What I generally do is throw the user's current page on my site into a
cookie and then have my bounceback page read the cookie and send the
user back to where they were. Sometimes it doesn't make sense to do it
(like they came from a page that doesn't make any sense once the user
is "connected"), so your particular logic might be more complex, but
it works. It also keeps it in your control rather than dealing with
the external dependency at all.
On Jul 24, 2:50 pm, Dennis Rybalchenko <sauronfromli...@gmail.com>
wrote:
> It seems that it is common issue for now. I also can not get redirect
> where i need, it only redirects to the default url, though i always
> get oauth_callback_confirmed=true .
> It needs some clarification from Tumblr guys.
> On 22 июл, 04:20, Travis Vachon <tra...@copious.com> wrote:
> > Hi there
> > I'm using omniauth to connect to tumblr in my app, and can't seem to
> > get tumblr to respect the value of oauth_callback I'm passing when I
> > get a request token. The request token request/response looks like:
> > Despite this, however, the response to the authorize call is always a
> > redirect to the default callback url I've configured in my tumblr
> > application:
> > Is this a known issue? FWIW, the twitter oauth api seems do the right
> > thing, and the request/response chain seems to be about the same
> > otherwise.
> > Thanks! Let me know if I can provide any more information.
Yeah, we're doing this too - the issue I'm having is that tumblr's oauth implementation doesn't seem to be respecting the callback URL Omniauth is passing, and instead always using the default callback I specified when I set up the application. This means that connecting to tumblr in my development application results in a call to my production app. I'm working around this for now by setting up per-environment applications with different default callbacks.
On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <travis.vac...@gmail.com> wrote: > Yeah, we're doing this too - the issue I'm having is that tumblr's > oauth implementation doesn't seem to be respecting the callback URL > Omniauth is passing, and instead always using the default callback I > specified when I set up the application. This means that connecting to > tumblr in my development application results in a call to my > production app. I'm working around this for now by setting up > per-environment applications with different default callbacks.
> t
> On Tue, Jul 26, 2011 at 9:25 AM, jesse <resistanceisfut...@gmail.com> wrote: >> For what it's worth, I've run into this with other APIs (FB springs to >> mind, although it may be fixed now).
>> What I generally do is throw the user's current page on my site into a >> cookie and then have my bounceback page read the cookie and send the >> user back to where they were. Sometimes it doesn't make sense to do it >> (like they came from a page that doesn't make any sense once the user >> is "connected"), so your particular logic might be more complex, but >> it works. It also keeps it in your control rather than dealing with >> the external dependency at all.
>> On Jul 24, 2:50 pm, Dennis Rybalchenko <sauronfromli...@gmail.com> >> wrote: >>> Hello.
>>> It seems that it is common issue for now. I also can not get redirect >>> where i need, it only redirects to the default url, though i always >>> get oauth_callback_confirmed=true . >>> It needs some clarification from Tumblr guys.
>>> On 22 июл, 04:20, Travis Vachon <tra...@copious.com> wrote:
>>> > Hi there
>>> > I'm using omniauth to connect to tumblr in my app, and can't seem to >>> > get tumblr to respect the value of oauth_callback I'm passing when I >>> > get a request token. The request token request/response looks like:
>>> > Despite this, however, the response to the authorize call is always a >>> > redirect to the default callback url I've configured in my tumblr >>> > application:
>>> > Is this a known issue? FWIW, the twitter oauth api seems do the right >>> > thing, and the request/response chain seems to be about the same >>> > otherwise.
>>> > Thanks! Let me know if I can provide any more information.
Oh. That's entirely different. In that scenario it sounds like Tumblr
is doing The Right Thing. An OAuth server should never allow a
callback to a different domain for the supplied keys.
On Jul 26, 2:21 pm, Travis Vachon <travis.vac...@gmail.com> wrote:
> Yeah, we're doing this too - the issue I'm having is that tumblr's
> oauth implementation doesn't seem to be respecting the callback URL
> Omniauth is passing, and instead always using the default callback I
> specified when I set up the application. This means that connecting to
> tumblr in my development application results in a call to my
> production app. I'm working around this for now by setting up
> per-environment applications with different default callbacks.
> t
> On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <travis.vac...@gmail.com> wrote:
> > Yeah, we're doing this too - the issue I'm having is that tumblr's
> > oauth implementation doesn't seem to be respecting the callback URL
> > Omniauth is passing, and instead always using the default callback I
> > specified when I set up the application. This means that connecting to
> > tumblr in my development application results in a call to my
> > production app. I'm working around this for now by setting up
> > per-environment applications with different default callbacks.
> > t
> > On Tue, Jul 26, 2011 at 9:25 AM, jesse <resistanceisfut...@gmail.com> wrote:
> >> For what it's worth, I've run into this with other APIs (FB springs to
> >> mind, although it may be fixed now).
> >> What I generally do is throw the user's current page on my site into a
> >> cookie and then have my bounceback page read the cookie and send the
> >> user back to where they were. Sometimes it doesn't make sense to do it
> >> (like they came from a page that doesn't make any sense once the user
> >> is "connected"), so your particular logic might be more complex, but
> >> it works. It also keeps it in your control rather than dealing with
> >> the external dependency at all.
> >> On Jul 24, 2:50 pm, Dennis Rybalchenko <sauronfromli...@gmail.com>
> >> wrote:
> >>> Hello.
> >>> It seems that it is common issue for now. I also can not get redirect
> >>> where i need, it only redirects to the default url, though i always
> >>> get oauth_callback_confirmed=true .
> >>> It needs some clarification from Tumblr guys.
> >>> On 22 июл, 04:20, Travis Vachon <tra...@copious.com> wrote:
> >>> > Hi there
> >>> > I'm using omniauth to connect to tumblr in my app, and can't seem to
> >>> > get tumblr to respect the value of oauth_callback I'm passing when I
> >>> > get a request token. The request token request/response looks like:
> >>> > Despite this, however, the response to the authorize call is always a
> >>> > redirect to the default callback url I've configured in my tumblr
> >>> > application:
> >>> > Is this a known issue? FWIW, the twitter oauth api seems do the right
> >>> > thing, and the request/response chain seems to be about the same
> >>> > otherwise.
> >>> > Thanks! Let me know if I can provide any more information.
Huh. This does seem to work with twitter's oauth implementation - we have one application set up, and twitter calls back to the correct per-environment domain. We've set up our development and staging environments as subdomains of our main domain (eg, local.copious.com), which perhaps explains why it works there.
On Tue, Jul 26, 2011 at 11:26 AM, jesse <resistanceisfut...@gmail.com> wrote: > Oh. That's entirely different. In that scenario it sounds like Tumblr > is doing The Right Thing. An OAuth server should never allow a > callback to a different domain for the supplied keys.
> On Jul 26, 2:21 pm, Travis Vachon <travis.vac...@gmail.com> wrote: >> Yeah, we're doing this too - the issue I'm having is that tumblr's >> oauth implementation doesn't seem to be respecting the callback URL >> Omniauth is passing, and instead always using the default callback I >> specified when I set up the application. This means that connecting to >> tumblr in my development application results in a call to my >> production app. I'm working around this for now by setting up >> per-environment applications with different default callbacks.
>> t
>> On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <travis.vac...@gmail.com> wrote: >> > Yeah, we're doing this too - the issue I'm having is that tumblr's >> > oauth implementation doesn't seem to be respecting the callback URL >> > Omniauth is passing, and instead always using the default callback I >> > specified when I set up the application. This means that connecting to >> > tumblr in my development application results in a call to my >> > production app. I'm working around this for now by setting up >> > per-environment applications with different default callbacks.
>> > t
>> > On Tue, Jul 26, 2011 at 9:25 AM, jesse <resistanceisfut...@gmail.com> wrote: >> >> For what it's worth, I've run into this with other APIs (FB springs to >> >> mind, although it may be fixed now).
>> >> What I generally do is throw the user's current page on my site into a >> >> cookie and then have my bounceback page read the cookie and send the >> >> user back to where they were. Sometimes it doesn't make sense to do it >> >> (like they came from a page that doesn't make any sense once the user >> >> is "connected"), so your particular logic might be more complex, but >> >> it works. It also keeps it in your control rather than dealing with >> >> the external dependency at all.
>> >> On Jul 24, 2:50 pm, Dennis Rybalchenko <sauronfromli...@gmail.com> >> >> wrote: >> >>> Hello.
>> >>> It seems that it is common issue for now. I also can not get redirect >> >>> where i need, it only redirects to the default url, though i always >> >>> get oauth_callback_confirmed=true . >> >>> It needs some clarification from Tumblr guys.
>> >>> On 22 июл, 04:20, Travis Vachon <tra...@copious.com> wrote:
>> >>> > Hi there
>> >>> > I'm using omniauth to connect to tumblr in my app, and can't seem to >> >>> > get tumblr to respect the value of oauth_callback I'm passing when I >> >>> > get a request token. The request token request/response looks like:
>> >>> > Despite this, however, the response to the authorize call is always a >> >>> > redirect to the default callback url I've configured in my tumblr >> >>> > application:
>> >>> > Is this a known issue? FWIW, the twitter oauth api seems do the right >> >>> > thing, and the request/response chain seems to be about the same >> >>> > otherwise.
>> >>> > Thanks! Let me know if I can provide any more information.
> Huh. This does seem to work with twitter's oauth implementation - we
> have one application set up, and twitter calls back to the correct
> per-environment domain. We've set up our development and staging
> environments as subdomains of our main domain (eg, local.copious.com),
> which perhaps explains why it works there.
> On Tue, Jul 26, 2011 at 11:26 AM, jesse <resistanceisfut...@gmail.com> wrote:
> > Oh. That's entirely different. In that scenario it sounds like Tumblr
> > is doing The Right Thing. An OAuth server should never allow a
> > callback to a different domain for the supplied keys.
> > On Jul 26, 2:21 pm, Travis Vachon <travis.vac...@gmail.com> wrote:
> >> Yeah, we're doing this too - the issue I'm having is that tumblr's
> >> oauth implementation doesn't seem to be respecting the callback URL
> >> Omniauth is passing, and instead always using the default callback I
> >> specified when I set up the application. This means that connecting to
> >> tumblr in my development application results in a call to my
> >> production app. I'm working around this for now by setting up
> >> per-environment applications with different default callbacks.
> >> t
> >> On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <travis.vac...@gmail.com> wrote:
> >> > Yeah, we're doing this too - the issue I'm having is that tumblr's
> >> > oauth implementation doesn't seem to be respecting the callback URL
> >> > Omniauth is passing, and instead always using the default callback I
> >> > specified when I set up the application. This means that connecting to
> >> > tumblr in my development application results in a call to my
> >> > production app. I'm working around this for now by setting up
> >> > per-environment applications with different default callbacks.
> >> > t
> >> > On Tue, Jul 26, 2011 at 9:25 AM, jesse <resistanceisfut...@gmail.com> wrote:
> >> >> For what it's worth, I've run into this with other APIs (FB springs to
> >> >> mind, although it may be fixed now).
> >> >> What I generally do is throw the user's current page on my site into a
> >> >> cookie and then have my bounceback page read the cookie and send the
> >> >> user back to where they were. Sometimes it doesn't make sense to do it
> >> >> (like they came from a page that doesn't make any sense once the user
> >> >> is "connected"), so your particular logic might be more complex, but
> >> >> it works. It also keeps it in your control rather than dealing with
> >> >> the external dependency at all.
> >> >> On Jul 24, 2:50 pm, Dennis Rybalchenko <sauronfromli...@gmail.com>
> >> >> wrote:
> >> >>> Hello.
> >> >>> It seems that it is common issue for now. I also can not get redirect
> >> >>> where i need, it only redirects to the default url, though i always
> >> >>> get oauth_callback_confirmed=true .
> >> >>> It needs some clarification from Tumblr guys.
> >> >>> > I'm using omniauth to connect to tumblr in my app, and can't seem to
> >> >>> > get tumblr to respect the value of oauth_callback I'm passing when I
> >> >>> > get a request token. The request token request/response looks like:
> >> >>> > Despite this, however, the response to the authorize call is always a
> >> >>> > redirect to the default callback url I've configured in my tumblr
> >> >>> > application:
> >> >>> > Is this a known issue? FWIW, the twitter oauth api seems do the right
> >> >>> > thing, and the request/response chain seems to be about the same
> >> >>> > otherwise.
> >> >>> > Thanks! Let me know if I can provide any more information.
Is this still the expected behavior, that the Tumblr API completely ignores the passed callback URL in favor of the application's registered callback_url?
We've been forced to register redundant applications so different hostnames can work: development, staging, production, so on and so forth.
This has been repeatedly filed as a bug against my omniauth-tumblr library (an authentication library for Ruby and Rails applications) since almost every other API respects this parameter:
On Tuesday, July 26, 2011 11:55:28 AM UTC-7, jesse wrote:
> That's interesting about Twitter. I don't recall that working in the > past, but I may have just never tried it.
> Subdomains working... I have mixed feelings, I guess it makes sense. > Great for devs, for sure.
> On Jul 26, 2:42 pm, Travis Vachon <travis.vac...@gmail.com> wrote: > > Huh. This does seem to work with twitter's oauth implementation - we > > have one application set up, and twitter calls back to the correct > > per-environment domain. We've set up our development and staging > > environments as subdomains of our main domain (eg, local.copious.com), > > which perhaps explains why it works there.
> > On Tue, Jul 26, 2011 at 11:26 AM, jesse <resistanceisfut...@gmail.com> > wrote: > > > Oh. That's entirely different. In that scenario it sounds like Tumblr > > > is doing The Right Thing. An OAuth server should never allow a > > > callback to a different domain for the supplied keys.
> > > On Jul 26, 2:21 pm, Travis Vachon <travis.vac...@gmail.com> wrote: > > >> Yeah, we're doing this too - the issue I'm having is that tumblr's > > >> oauth implementation doesn't seem to be respecting the callback URL > > >> Omniauth is passing, and instead always using the default callback I > > >> specified when I set up the application. This means that connecting > to > > >> tumblr in my development application results in a call to my > > >> production app. I'm working around this for now by setting up > > >> per-environment applications with different default callbacks.
> > >> t
> > >> On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <
> travis.vac...@gmail.com> wrote: > > >> > Yeah, we're doing this too - the issue I'm having is that tumblr's > > >> > oauth implementation doesn't seem to be respecting the callback URL > > >> > Omniauth is passing, and instead always using the default callback > I > > >> > specified when I set up the application. This means that connecting > to > > >> > tumblr in my development application results in a call to my > > >> > production app. I'm working around this for now by setting up > > >> > per-environment applications with different default callbacks.
> > >> > t
> > >> > On Tue, Jul 26, 2011 at 9:25 AM, jesse <
> resistanceisfut...@gmail.com> wrote: > > >> >> For what it's worth, I've run into this with other APIs (FB > springs to > > >> >> mind, although it may be fixed now).
> > >> >> What I generally do is throw the user's current page on my site > into a > > >> >> cookie and then have my bounceback page read the cookie and send > the > > >> >> user back to where they were. Sometimes it doesn't make sense to > do it > > >> >> (like they came from a page that doesn't make any sense once the > user > > >> >> is "connected"), so your particular logic might be more complex, > but > > >> >> it works. It also keeps it in your control rather than dealing > with > > >> >> the external dependency at all.
> > >> >> On Jul 24, 2:50 pm, Dennis Rybalchenko <sauronfromli...@gmail.com>
> > >> >> wrote: > > >> >>> Hello.
> > >> >>> It seems that it is common issue for now. I also can not get > redirect > > >> >>> where i need, it only redirects to the default url, though i > always > > >> >>> get oauth_callback_confirmed=true . > > >> >>> It needs some clarification from Tumblr guys.
> > >> >>> > I'm using omniauth to connect to tumblr in my app, and can't > seem to > > >> >>> > get tumblr to respect the value of oauth_callback I'm passing > when I > > >> >>> > get a request token. The request token request/response looks > like:
> > >> >>> > Despite this, however, the response to the authorize call is > always a > > >> >>> > redirect to the default callback url I've configured in my > tumblr > > >> >>> > application:
> > >> >>> > Is this a known issue? FWIW, the twitter oauth api seems do the > right > > >> >>> > thing, and the request/response chain seems to be about the > same > > >> >>> > otherwise.
> > >> >>> > Thanks! Let me know if I can provide any more information.
Bump to this - I am using the callback to perform app switching on iOS, but the URL will need be different if I use Android or another platform. The API seems to ignore oauth_callback and revert to the default callback as reported by Jamie.
On Saturday, August 4, 2012 6:45:18 PM UTC+1, Jamie Wilkinson wrote:
> Is this still the expected behavior, that the Tumblr API completely > ignores the passed callback URL in favor of the application's registered > callback_url?
> We've been forced to register redundant applications so different > hostnames can work: development, staging, production, so on and so forth.
> This has been repeatedly filed as a bug against my omniauth-tumblr library > (an authentication library for Ruby and Rails applications) since almost > every other API respects this parameter:
> On Tuesday, July 26, 2011 11:55:28 AM UTC-7, jesse wrote:
>> That's interesting about Twitter. I don't recall that working in the >> past, but I may have just never tried it.
>> Subdomains working... I have mixed feelings, I guess it makes sense. >> Great for devs, for sure.
>> On Jul 26, 2:42 pm, Travis Vachon <travis.vac...@gmail.com> wrote: >> > Huh. This does seem to work with twitter's oauth implementation - we >> > have one application set up, and twitter calls back to the correct >> > per-environment domain. We've set up our development and staging >> > environments as subdomains of our main domain (eg, local.copious.com), >> > which perhaps explains why it works there.
>> > On Tue, Jul 26, 2011 at 11:26 AM, jesse <resistanceisfut...@gmail.com> >> wrote: >> > > Oh. That's entirely different. In that scenario it sounds like Tumblr >> > > is doing The Right Thing. An OAuth server should never allow a >> > > callback to a different domain for the supplied keys.
>> > > On Jul 26, 2:21 pm, Travis Vachon <travis.vac...@gmail.com> wrote: >> > >> Yeah, we're doing this too - the issue I'm having is that tumblr's >> > >> oauth implementation doesn't seem to be respecting the callback URL >> > >> Omniauth is passing, and instead always using the default callback I >> > >> specified when I set up the application. This means that connecting >> to >> > >> tumblr in my development application results in a call to my >> > >> production app. I'm working around this for now by setting up >> > >> per-environment applications with different default callbacks.
>> > >> t
>> > >> On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <
>> travis.vac...@gmail.com> wrote: >> > >> > Yeah, we're doing this too - the issue I'm having is that tumblr's >> > >> > oauth implementation doesn't seem to be respecting the callback >> URL >> > >> > Omniauth is passing, and instead always using the default callback >> I >> > >> > specified when I set up the application. This means that >> connecting to >> > >> > tumblr in my development application results in a call to my >> > >> > production app. I'm working around this for now by setting up >> > >> > per-environment applications with different default callbacks.
>> > >> > t
>> > >> > On Tue, Jul 26, 2011 at 9:25 AM, jesse <
>> resistanceisfut...@gmail.com> wrote: >> > >> >> For what it's worth, I've run into this with other APIs (FB >> springs to >> > >> >> mind, although it may be fixed now).
>> > >> >> What I generally do is throw the user's current page on my site >> into a >> > >> >> cookie and then have my bounceback page read the cookie and send >> the >> > >> >> user back to where they were. Sometimes it doesn't make sense to >> do it >> > >> >> (like they came from a page that doesn't make any sense once the >> user >> > >> >> is "connected"), so your particular logic might be more complex, >> but >> > >> >> it works. It also keeps it in your control rather than dealing >> with >> > >> >> the external dependency at all.
>> > >> >> On Jul 24, 2:50 pm, Dennis Rybalchenko <sauronfromli...@gmail.com>
>> > >> >> wrote: >> > >> >>> Hello.
>> > >> >>> It seems that it is common issue for now. I also can not get >> redirect >> > >> >>> where i need, it only redirects to the default url, though i >> always >> > >> >>> get oauth_callback_confirmed=true . >> > >> >>> It needs some clarification from Tumblr guys.
>> > >> >>> > I'm using omniauth to connect to tumblr in my app, and can't >> seem to >> > >> >>> > get tumblr to respect the value of oauth_callback I'm passing >> when I >> > >> >>> > get a request token. The request token request/response looks >> like:
>> > >> >>> > Despite this, however, the response to the authorize call is >> always a >> > >> >>> > redirect to the default callback url I've configured in my >> tumblr >> > >> >>> > application:
>> > >> >>> > Is this a known issue? FWIW, the twitter oauth api seems do >> the right >> > >> >>> > thing, and the request/response chain seems to be about the >> same >> > >> >>> > otherwise.
>> > >> >>> > Thanks! Let me know if I can provide any more information.
On Wed, Oct 24, 2012 at 5:26 AM, Alex <alexander.e...@googlemail.com> wrote:
> Bump to this - I am using the callback to perform app switching on iOS,
> but the URL will need be different if I use Android or another platform.
> The API seems to ignore oauth_callback and revert to the default callback
> as reported by Jamie.
> On Saturday, August 4, 2012 6:45:18 PM UTC+1, Jamie Wilkinson wrote:
>> Is this still the expected behavior, that the Tumblr API completely
>> ignores the passed callback URL in favor of the application's registered
>> callback_url?
>> We've been forced to register redundant applications so different
>> hostnames can work: development, staging, production, so on and so forth.
>> This has been repeatedly filed as a bug against my omniauth-tumblr
>> library (an authentication library for Ruby and Rails applications) since
>> almost every other API respects this parameter:
>> On Tuesday, July 26, 2011 11:55:28 AM UTC-7, jesse wrote:
>>> That's interesting about Twitter. I don't recall that working in the
>>> past, but I may have just never tried it.
>>> Subdomains working... I have mixed feelings, I guess it makes sense.
>>> Great for devs, for sure.
>>> On Jul 26, 2:42 pm, Travis Vachon <travis.vac...@gmail.com> wrote:
>>> > Huh. This does seem to work with twitter's oauth implementation - we
>>> > have one application set up, and twitter calls back to the correct
>>> > per-environment domain. We've set up our development and staging
>>> > environments as subdomains of our main domain (eg, local.copious.com),
>>> > which perhaps explains why it works there.
>>> > On Tue, Jul 26, 2011 at 11:26 AM, jesse <resistanceisfut...@gmail.com>
>>> wrote:
>>> > > Oh. That's entirely different. In that scenario it sounds like
>>> Tumblr
>>> > > is doing The Right Thing. An OAuth server should never allow a
>>> > > callback to a different domain for the supplied keys.
>>> > > On Jul 26, 2:21 pm, Travis Vachon <travis.vac...@gmail.com> wrote:
>>> > >> Yeah, we're doing this too - the issue I'm having is that tumblr's
>>> > >> oauth implementation doesn't seem to be respecting the callback URL
>>> > >> Omniauth is passing, and instead always using the default callback
>>> I
>>> > >> specified when I set up the application. This means that connecting
>>> to
>>> > >> tumblr in my development application results in a call to my
>>> > >> production app. I'm working around this for now by setting up
>>> > >> per-environment applications with different default callbacks.
>>> > >> t
>>> > >> On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <
>>> travis.vac...@gmail.com> wrote:
>>> > >> > Yeah, we're doing this too - the issue I'm having is that
>>> tumblr's
>>> > >> > oauth implementation doesn't seem to be respecting the callback
>>> URL
>>> > >> > Omniauth is passing, and instead always using the default
>>> callback I
>>> > >> > specified when I set up the application. This means that
>>> connecting to
>>> > >> > tumblr in my development application results in a call to my
>>> > >> > production app. I'm working around this for now by setting up
>>> > >> > per-environment applications with different default callbacks.
>>> > >> > t
>>> > >> > On Tue, Jul 26, 2011 at 9:25 AM, jesse <
>>> resistanceisfut...@gmail.com> wrote:
>>> > >> >> For what it's worth, I've run into this with other APIs (FB
>>> springs to
>>> > >> >> mind, although it may be fixed now).
>>> > >> >> What I generally do is throw the user's current page on my site
>>> into a
>>> > >> >> cookie and then have my bounceback page read the cookie and send
>>> the
>>> > >> >> user back to where they were. Sometimes it doesn't make sense to
>>> do it
>>> > >> >> (like they came from a page that doesn't make any sense once the
>>> user
>>> > >> >> is "connected"), so your particular logic might be more complex,
>>> but
>>> > >> >> it works. It also keeps it in your control rather than dealing
>>> with
>>> > >> >> the external dependency at all.
>>> > >> >>> It seems that it is common issue for now. I also can not get
>>> redirect
>>> > >> >>> where i need, it only redirects to the default url, though i
>>> always
>>> > >> >>> get oauth_callback_confirmed=true .
>>> > >> >>> It needs some clarification from Tumblr guys.
>>> > >> >>> > I'm using omniauth to connect to tumblr in my app, and can't
>>> seem to
>>> > >> >>> > get tumblr to respect the value of oauth_callback I'm passing
>>> when I
>>> > >> >>> > get a request token. The request token request/response looks
>>> like:
>>> > >> >>> > Despite this, however, the response to the authorize call is
>>> always a
>>> > >> >>> > redirect to the default callback url I've configured in my
>>> tumblr
>>> > >> >>> > application:
>>> > >> >>> > Is this a known issue? FWIW, the twitter oauth api seems do
>>> the right
>>> > >> >>> > thing, and the request/response chain seems to be about the
>>> same
>>> > >> >>> > otherwise.
>>> > >> >>> > Thanks! Let me know if I can provide any more information.
>>> > >> >>> > Travis
-- John Bunting
Simplicity is prerequisite for reliability
--Edsger W. Dijkstra
I found this on Ruby, but perhaps it will help you with iOS -- the oauth_callback is not specified in the get_request_token call as it is with Twitter, it is instead added to the end of the authorize_url. I put it all here: http://stackoverflow.com/questions/7786644/tumblr-oauth-callback-url/...
On Wednesday, October 24, 2012 5:26:51 AM UTC-4, Alex wrote:
> Bump to this - I am using the callback to perform app switching on iOS, > but the URL will need be different if I use Android or another platform. > The API seems to ignore oauth_callback and revert to the default callback > as reported by Jamie.
> On Saturday, August 4, 2012 6:45:18 PM UTC+1, Jamie Wilkinson wrote:
>> Is this still the expected behavior, that the Tumblr API completely >> ignores the passed callback URL in favor of the application's registered >> callback_url?
>> We've been forced to register redundant applications so different >> hostnames can work: development, staging, production, so on and so forth.
>> This has been repeatedly filed as a bug against my omniauth-tumblr >> library (an authentication library for Ruby and Rails applications) since >> almost every other API respects this parameter:
>> On Tuesday, July 26, 2011 11:55:28 AM UTC-7, jesse wrote:
>>> That's interesting about Twitter. I don't recall that working in the >>> past, but I may have just never tried it.
>>> Subdomains working... I have mixed feelings, I guess it makes sense. >>> Great for devs, for sure.
>>> On Jul 26, 2:42 pm, Travis Vachon <travis.vac...@gmail.com> wrote: >>> > Huh. This does seem to work with twitter's oauth implementation - we >>> > have one application set up, and twitter calls back to the correct >>> > per-environment domain. We've set up our development and staging >>> > environments as subdomains of our main domain (eg, local.copious.com),
>>> > which perhaps explains why it works there.
>>> > On Tue, Jul 26, 2011 at 11:26 AM, jesse <resistanceisfut...@gmail.com> >>> wrote: >>> > > Oh. That's entirely different. In that scenario it sounds like >>> Tumblr >>> > > is doing The Right Thing. An OAuth server should never allow a >>> > > callback to a different domain for the supplied keys.
>>> > > On Jul 26, 2:21 pm, Travis Vachon <travis.vac...@gmail.com> wrote: >>> > >> Yeah, we're doing this too - the issue I'm having is that tumblr's >>> > >> oauth implementation doesn't seem to be respecting the callback URL >>> > >> Omniauth is passing, and instead always using the default callback >>> I >>> > >> specified when I set up the application. This means that connecting >>> to >>> > >> tumblr in my development application results in a call to my >>> > >> production app. I'm working around this for now by setting up >>> > >> per-environment applications with different default callbacks.
>>> > >> t
>>> > >> On Tue, Jul 26, 2011 at 11:17 AM, Travis Vachon <
>>> travis.vac...@gmail.com> wrote: >>> > >> > Yeah, we're doing this too - the issue I'm having is that >>> tumblr's >>> > >> > oauth implementation doesn't seem to be respecting the callback >>> URL >>> > >> > Omniauth is passing, and instead always using the default >>> callback I >>> > >> > specified when I set up the application. This means that >>> connecting to >>> > >> > tumblr in my development application results in a call to my >>> > >> > production app. I'm working around this for now by setting up >>> > >> > per-environment applications with different default callbacks.
>>> > >> > t
>>> > >> > On Tue, Jul 26, 2011 at 9:25 AM, jesse <
>>> resistanceisfut...@gmail.com> wrote: >>> > >> >> For what it's worth, I've run into this with other APIs (FB >>> springs to >>> > >> >> mind, although it may be fixed now).
>>> > >> >> What I generally do is throw the user's current page on my site >>> into a >>> > >> >> cookie and then have my bounceback page read the cookie and send >>> the >>> > >> >> user back to where they were. Sometimes it doesn't make sense to >>> do it >>> > >> >> (like they came from a page that doesn't make any sense once the >>> user >>> > >> >> is "connected"), so your particular logic might be more complex, >>> but >>> > >> >> it works. It also keeps it in your control rather than dealing >>> with >>> > >> >> the external dependency at all.
>>> > >> >>> It seems that it is common issue for now. I also can not get >>> redirect >>> > >> >>> where i need, it only redirects to the default url, though i >>> always >>> > >> >>> get oauth_callback_confirmed=true . >>> > >> >>> It needs some clarification from Tumblr guys.
>>> > >> >>> > I'm using omniauth to connect to tumblr in my app, and can't >>> seem to >>> > >> >>> > get tumblr to respect the value of oauth_callback I'm passing >>> when I >>> > >> >>> > get a request token. The request token request/response looks >>> like:
>>> > >> >>> > Despite this, however, the response to the authorize call is >>> always a >>> > >> >>> > redirect to the default callback url I've configured in my >>> tumblr >>> > >> >>> > application:
>>> > >> >>> > Is this a known issue? FWIW, the twitter oauth api seems do >>> the right >>> > >> >>> > thing, and the request/response chain seems to be about the >>> same >>> > >> >>> > otherwise.
>>> > >> >>> > Thanks! Let me know if I can provide any more information.
