New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

signup API for @idno #240

Closed
snarfed opened this Issue Jul 29, 2014 · 32 comments

Comments

Projects
None yet
4 participants
@snarfed
Owner

snarfed commented Jul 29, 2014

@benwerd recently mentioned that @idno would like an API for signup, ie a way that Known users can click a button inside Known to start bridgy signup, go directly to the silo oauth prompt, and then redirect back to Known, ideally without seeing a bridgy page at all - or if they do, make it an obvious part of the known UX flow.

i like it! totally doable. here's a straw man: we add a query parameter to the bridgy signup URL to specify where to redirect the user after it's done. if provided, and (probably) if it matches a whitelist, we'd redirect there at the end instead of to the bridgy user page.

open questions:

  • i think i want the redirect whitelist, but that doesn't really work for self-hosted known instances. we could initially do this for only known-as-a-service, and see how it goes.
  • the silo oauth prompts will show bridgy's name and logo, not known's. this could be a problem for novice users, and could cause dropoff. one solution is to use separate api keys with known's name and logo, but i'd rather not do that if we can help it.
  • user education. this will blur the line between known and bridgy, and contribute to people thinking that this is a known feature instead of a separate service. that's fine with me, but it will cause problems when they need support. for example, i (maybe?) still want users to know about their brid.gy user page, which shows info on their recent responses. (in the long run, known might prefer to do its own backfeed, which totally makes sense, but is a lot of work to tackle.)

@benwerd, thoughts?

@snarfed snarfed added maybe and removed maybe labels Jul 29, 2014

@snarfed snarfed removed the maybe label Sep 4, 2014

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Sep 24, 2014

Almost two months later, I want to finally weigh in here and say, yay! This would be awesome. Part of the integration discussion I'd like to take offline (although sadly not at today's Homebrew).

Some feedback and ideas:

  • We're mostly interested in Known-as-a-service at this stage. Our assumption is that self-installers have the technical understanding to find their way to http://brid.gy, and we want to make the documentation in that vein clearer and more emphatic :)
  • I'm not hugely worried about the logo for now - presumably we would need to run our own separate instance to change those. I think that's definitely worth talking about, fwiw, in collaboration with this community.
  • I'm cool with saying something like "powered by bridgy" and making the link clear.

We have one big need that I'd like to figure out:

  • We don't want the user's indieweb-capable site to need to be in the user's URL field on (eg) Twitter, and would prefer to pass this site in via the API. So it should just work, even if they chose to list http://yahoo.com as their homepage.

Let us know how we can be most helpful, and if some of these are completely out of bounds :)

Ben

benwerd commented Sep 24, 2014

Almost two months later, I want to finally weigh in here and say, yay! This would be awesome. Part of the integration discussion I'd like to take offline (although sadly not at today's Homebrew).

Some feedback and ideas:

  • We're mostly interested in Known-as-a-service at this stage. Our assumption is that self-installers have the technical understanding to find their way to http://brid.gy, and we want to make the documentation in that vein clearer and more emphatic :)
  • I'm not hugely worried about the logo for now - presumably we would need to run our own separate instance to change those. I think that's definitely worth talking about, fwiw, in collaboration with this community.
  • I'm cool with saying something like "powered by bridgy" and making the link clear.

We have one big need that I'd like to figure out:

  • We don't want the user's indieweb-capable site to need to be in the user's URL field on (eg) Twitter, and would prefer to pass this site in via the API. So it should just work, even if they chose to list http://yahoo.com as their homepage.

Let us know how we can be most helpful, and if some of these are completely out of bounds :)

Ben

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Sep 25, 2014

Owner

hey @benwerd, glad to hear you're thinking about this! and congrats on launching the hosted service!

all of those points make sense, and happily bridgy mostly doesn't care whether your (indie) web site URL is in your silo profile. it tries to send webmentions to all links it finds.

the one catch is that it would need that URL if you want backfeed for tweets that don't link (or PSC/PSL) to the original post at all...which i expect you do want. to support that, sure, we could add a separate, explicit homepage field that the API could populate.

otherwise, does the straw man idea sound ok? ie, at some point in your signup flow, you'd have the user POST to a bridgy URL, which would transparently set up their account, have them auth with the silo, then immediately send them back to a Known callback URL that you provide. they'd only see the silo oauth prompt and your pages before and after. seems simpler than a full fledged JSON RPC style API, and it should let us do everything we need.

i suddenly have a lot less free time (you may have seen why :P), so no guarantees, but this should all be pretty straightforward and not much work.

Owner

snarfed commented Sep 25, 2014

hey @benwerd, glad to hear you're thinking about this! and congrats on launching the hosted service!

all of those points make sense, and happily bridgy mostly doesn't care whether your (indie) web site URL is in your silo profile. it tries to send webmentions to all links it finds.

the one catch is that it would need that URL if you want backfeed for tweets that don't link (or PSC/PSL) to the original post at all...which i expect you do want. to support that, sure, we could add a separate, explicit homepage field that the API could populate.

otherwise, does the straw man idea sound ok? ie, at some point in your signup flow, you'd have the user POST to a bridgy URL, which would transparently set up their account, have them auth with the silo, then immediately send them back to a Known callback URL that you provide. they'd only see the silo oauth prompt and your pages before and after. seems simpler than a full fledged JSON RPC style API, and it should let us do everything we need.

i suddenly have a lot less free time (you may have seen why :P), so no guarantees, but this should all be pretty straightforward and not much work.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Sep 25, 2014

Collaborator

/me flags self as being willing to help on this.

Collaborator

kylewm commented Sep 25, 2014

/me flags self as being willing to help on this.

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Sep 25, 2014

Owner

awesome, thanks @kylewm!

Owner

snarfed commented Sep 25, 2014

awesome, thanks @kylewm!

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Sep 25, 2014

Incredibly cool, and congratulations @snarfed!

@kylewm, I'd love to catch up and chat about all of this. Had to miss Homebrew yesterday, but it'd be great to meet up if you have some time over the next week or two?

benwerd commented Sep 25, 2014

Incredibly cool, and congratulations @snarfed!

@kylewm, I'd love to catch up and chat about all of this. Had to miss Homebrew yesterday, but it'd be great to meet up if you have some time over the next week or two?

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 6, 2014

Collaborator

progress update: my folks were in town this weekend, didn't have a whole ton of time and got a little hung up on overescaping/underescaping the "state" parameter. but I'm done with the registration redirect part (still need to write unit tests), and the custom author URL setting.

Collaborator

kylewm commented Oct 6, 2014

progress update: my folks were in town this weekend, didn't have a whole ton of time and got a little hung up on overescaping/underescaping the "state" parameter. but I'm done with the registration redirect part (still need to write unit tests), and the custom author URL setting.

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 6, 2014

Owner

awesome! thanks for the status update. no need to apologize; that's plenty of progress!

btw, feel free to use your judgment on cost/benefit for whether/what to unit test. nontrivial logic is nice to test when possible, but i've obviously skipped it for big chunks of code, e.g. all of oauth-dropins and pretty much all of bridgy's UI.

Owner

snarfed commented Oct 6, 2014

awesome! thanks for the status update. no need to apologize; that's plenty of progress!

btw, feel free to use your judgment on cost/benefit for whether/what to unit test. nontrivial logic is nice to test when possible, but i've obviously skipped it for big chunks of code, e.g. all of oauth-dropins and pretty much all of bridgy's UI.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 6, 2014

Collaborator

thanks, and oops I edited that incorrectly! should have read "still need to write unit tests and the custom author URL setting." 👅

Collaborator

kylewm commented Oct 6, 2014

thanks, and oops I edited that incorrectly! should have read "still need to write unit tests and the custom author URL setting." 👅

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Oct 6, 2014

This is exceptionally cool.

Let us know what we can do at our end to help test!

On Mon, Oct 6, 2014 at 9:49 AM, Kyle Mahan notifications@github.com wrote:

progress update: my folks were in town this weekend, didn't have a whole
ton of time and got a little hung up on overescaping/underescaping the
"state" parameter. but I'm done with the registration redirect part (still
need to write unit tests), and the custom author URL setting.


Reply to this email directly or view it on GitHub
#240 (comment).

Ben Werdmuller
http://goog_1933028737
benwerd.com | werd.io

+1 (312) 488-9373

benwerd commented Oct 6, 2014

This is exceptionally cool.

Let us know what we can do at our end to help test!

On Mon, Oct 6, 2014 at 9:49 AM, Kyle Mahan notifications@github.com wrote:

progress update: my folks were in town this weekend, didn't have a whole
ton of time and got a little hung up on overescaping/underescaping the
"state" parameter. but I'm done with the registration redirect part (still
need to write unit tests), and the custom author URL setting.


Reply to this email directly or view it on GitHub
#240 (comment).

Ben Werdmuller
http://goog_1933028737
benwerd.com | werd.io

+1 (312) 488-9373

@physcocode

This comment has been minimized.

Show comment
Hide comment
@physcocode

physcocode Oct 7, 2014

That's cool ! I was just thinking to provide a sign up to bridgy URL in profile section of known , but this idea is much better great work @snarfed @benwerd .

physcocode commented Oct 7, 2014

That's cool ! I was just thinking to provide a sign up to bridgy URL in profile section of known , but this idea is much better great work @snarfed @benwerd .

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 8, 2014

Collaborator

I pushed changes for part 1 (support a callback parameter on /twitter/start and /facebook/start) with 2 unit tests. Deployed to my (public) test app https://bridgy-kwm.appspot.com. (Though Facebook right now doesn't work because bridgy's app key is tied to a specific callback URL).

Here is an example with curl:

(venv)kmahan@lemur:~/projects/bridgy$ curl -i https://bridgy-kwm.appspot.com/twitter/start -d "feature=listen&callback=http://example.com/"
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Location: https://api.twitter.com/oauth/authorize?oauth_token=sVx1ZgjXHSXrUGZ0IssLxACs12IarIQb
Date: Wed, 08 Oct 2014 06:08:22 GMT
Server: Google Frontend
Content-Length: 0
Alternate-Protocol: 443:quic,p=0.01

Still need to do the custom author URL bit. @snarfed I was thinking about just pre-pending this to the list of author URLs we already have per-Source, rather than saving it any kind of special custom override field. Let me know if that seems like it will cause problems!

Collaborator

kylewm commented Oct 8, 2014

I pushed changes for part 1 (support a callback parameter on /twitter/start and /facebook/start) with 2 unit tests. Deployed to my (public) test app https://bridgy-kwm.appspot.com. (Though Facebook right now doesn't work because bridgy's app key is tied to a specific callback URL).

Here is an example with curl:

(venv)kmahan@lemur:~/projects/bridgy$ curl -i https://bridgy-kwm.appspot.com/twitter/start -d "feature=listen&callback=http://example.com/"
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Location: https://api.twitter.com/oauth/authorize?oauth_token=sVx1ZgjXHSXrUGZ0IssLxACs12IarIQb
Date: Wed, 08 Oct 2014 06:08:22 GMT
Server: Google Frontend
Content-Length: 0
Alternate-Protocol: 443:quic,p=0.01

Still need to do the custom author URL bit. @snarfed I was thinking about just pre-pending this to the list of author URLs we already have per-Source, rather than saving it any kind of special custom override field. Let me know if that seems like it will cause problems!

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 8, 2014

Owner

awesome! i'll take a look now.

i like the idea of just putting the custom author URL first in the list. the only concern is that if they ever sign up again through bridgy directly, it'll get overwritten. that's probably fine, but @benwerd and @erinjo can correct me if i'm wrong.

Owner

snarfed commented Oct 8, 2014

awesome! i'll take a look now.

i like the idea of just putting the custom author URL first in the list. the only concern is that if they ever sign up again through bridgy directly, it'll get overwritten. that's probably fine, but @benwerd and @erinjo can correct me if i'm wrong.

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 8, 2014

Owner

so just to confirm my understanding, if known's setup flow has their user POST to e.g. https://www.brid.gy/facebook/start?feature=listen&callback=http://withknown.com/next/page, it will show them the facebook auth prompt, sign them up for bridgy (listen), then send them back to http://withknown.com/next/page? sgtm if so!

we'll eventually also want to think about 1) handling auth declines, maybe by adding a result param to the callback, or using a different callback, and 2) supporting delete too. both should be straightforward.

Owner

snarfed commented Oct 8, 2014

so just to confirm my understanding, if known's setup flow has their user POST to e.g. https://www.brid.gy/facebook/start?feature=listen&callback=http://withknown.com/next/page, it will show them the facebook auth prompt, sign them up for bridgy (listen), then send them back to http://withknown.com/next/page? sgtm if so!

we'll eventually also want to think about 1) handling auth declines, maybe by adding a result param to the callback, or using a different callback, and 2) supporting delete too. both should be straightforward.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 8, 2014

Collaborator

Yep, you got it.

Good point about declines and deletes. Right now declining in particular would dump them out in brid.gy/ probably utterly confused. I will go ahead and add callback with ?result=declined... very open to other phrasings.

Deletes are (only a little) more through-going, I'll hold off on those for now.

Collaborator

kylewm commented Oct 8, 2014

Yep, you got it.

Good point about declines and deletes. Right now declining in particular would dump them out in brid.gy/ probably utterly confused. I will go ahead and add callback with ?result=declined... very open to other phrasings.

Deletes are (only a little) more through-going, I'll hold off on those for now.

kylewm added a commit that referenced this issue Oct 8, 2014

support external registration callback for declines
- redirect to callback with ?result=declined
- also process review feedback from @snarfed

issue #240
@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 8, 2014

Collaborator

Added callback with ?result=declined and processed feedback from the last commit (Thanks!)

BTW, pushing to master is OK? Would a feature branch be better?

Collaborator

kylewm commented Oct 8, 2014

Added callback with ?result=declined and processed feedback from the last commit (Thanks!)

BTW, pushing to master is OK? Would a feature branch be better?

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 9, 2014

Owner

great!

pushing to master is fine with me. i obviously always do it myself. :P you're welcome to use branches too if you want though, up to you.

Owner

snarfed commented Oct 9, 2014

great!

pushing to master is fine with me. i obviously always do it myself. :P you're welcome to use branches too if you want though, up to you.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 9, 2014

Collaborator

hey @benwerd, @erinjo, all the functionality's there; we're just cleaning up and improving the tests now. I'm optimistic we can deploy before IWC starts on Saturday!

Collaborator

kylewm commented Oct 9, 2014

hey @benwerd, @erinjo, all the functionality's there; we're just cleaning up and improving the tests now. I'm optimistic we can deploy before IWC starts on Saturday!

kylewm referenced this issue Oct 10, 2014

registration callback: move tests to util_test
- changed util.oauth_starter to take the StartHandler class itself
  rather than the module (to make constructing a test handler a little
  easier)
- moved unit tests out of twitter_test and facebook_test and
  into util_test with FakeSource and FakeAuthEntity
- added unit test for a provided user_url; if provided this url is
  prepended to Source.domain_urls and Source.domains
@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 10, 2014

Collaborator

deployed! logs look good so far. the only thing I haven't been able to figure out is on the redirect from facebook I always get a fragment #_=_, even though I explicitly try to avoid this by using super.redirect here https://github.com/snarfed/bridgy/blob/master/util.py#L388

until I update the README, here are the endpoints and parameters. POST to these endpoints with the parameters urlencode as the post body

endpoints:

  • /twitter/start
  • /facebook/start

parameters:

  • feature: 'listen' or 'publish' -- required
  • callback: external url to call back to when authentication is complete -- optional
  • user_url: author's url, supersedes the url normally set from the silo profile -- optional

par exemple

kmahan@lemur:~$ curl -i https://www.brid.gy/facebook/start -d "feature=listen&callback=https://kylewm.com/bridgy_callback&user_url=https://kylewm.com"
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Location: https://www.facebook.com/dialog/oauth?scope=&client_id=...&redirect_uri=https%3A%2F%2Fwww.brid.gy%2Ffacebook%2Fadd%3Fstate%3D%257B%2522callback%2522%253A%2522https%253A%252F%252Fkylewm.com%252Fbridgy_callback%2522%252C%2522feature%2522%253A%2522listen%2522%252C%2522operation%2522%253A%2522add%2522%252C%2522user_url%2522%253A%2522https%253A%252F%252Fkylewm.com%2522%257D&response_type=code
Date: Fri, 10 Oct 2014 15:46:38 GMT
Server: Google Frontend
Content-Length: 0
Collaborator

kylewm commented Oct 10, 2014

deployed! logs look good so far. the only thing I haven't been able to figure out is on the redirect from facebook I always get a fragment #_=_, even though I explicitly try to avoid this by using super.redirect here https://github.com/snarfed/bridgy/blob/master/util.py#L388

until I update the README, here are the endpoints and parameters. POST to these endpoints with the parameters urlencode as the post body

endpoints:

  • /twitter/start
  • /facebook/start

parameters:

  • feature: 'listen' or 'publish' -- required
  • callback: external url to call back to when authentication is complete -- optional
  • user_url: author's url, supersedes the url normally set from the silo profile -- optional

par exemple

kmahan@lemur:~$ curl -i https://www.brid.gy/facebook/start -d "feature=listen&callback=https://kylewm.com/bridgy_callback&user_url=https://kylewm.com"
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Cache-Control: no-cache
Location: https://www.facebook.com/dialog/oauth?scope=&client_id=...&redirect_uri=https%3A%2F%2Fwww.brid.gy%2Ffacebook%2Fadd%3Fstate%3D%257B%2522callback%2522%253A%2522https%253A%252F%252Fkylewm.com%252Fbridgy_callback%2522%252C%2522feature%2522%253A%2522listen%2522%252C%2522operation%2522%253A%2522add%2522%252C%2522user_url%2522%253A%2522https%253A%252F%252Fkylewm.com%2522%257D&response_type=code
Date: Fri, 10 Oct 2014 15:46:38 GMT
Server: Google Frontend
Content-Length: 0
@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 10, 2014

Owner

awesome! looks great. thanks again for implenting this. can't wait to see what @idno does with it!

Owner

snarfed commented Oct 10, 2014

awesome! looks great. thanks again for implenting this. can't wait to see what @idno does with it!

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Oct 20, 2014

Collaborator

@aaronpk suggested it would be a good idea to sign the JSON-encoded state parameter with JWT, so that intermediaries can't monkey with it. Right now there is not much damage that someone could do by changing the state parameter -- they could make bridgy think it has more permissions than it does -- but it seems like it could be a good idea anyway.

And if that's OK, how do you feel about a new dependency on PyJWT (it's very small) https://github.com/progrium/pyjwt

Collaborator

kylewm commented Oct 20, 2014

@aaronpk suggested it would be a good idea to sign the JSON-encoded state parameter with JWT, so that intermediaries can't monkey with it. Right now there is not much damage that someone could do by changing the state parameter -- they could make bridgy think it has more permissions than it does -- but it seems like it could be a good idea anyway.

And if that's OK, how do you feel about a new dependency on PyJWT (it's very small) https://github.com/progrium/pyjwt

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Oct 20, 2014

Owner

interesting! definitely a good consideration.

I might push back a bit, though. it is a nontrivial addition, a new dependency, and makes the URLs less inspectable/debuggable, and there's arguably no meaningful threat right now.

maybe we wait to do it until if/when we add more sensitive parameters? I'm happy to leave this open to help us remember.

Owner

snarfed commented Oct 20, 2014

interesting! definitely a good consideration.

I might push back a bit, though. it is a nontrivial addition, a new dependency, and makes the URLs less inspectable/debuggable, and there's arguably no meaningful threat right now.

maybe we wait to do it until if/when we add more sensitive parameters? I'm happy to leave this open to help us remember.

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Nov 5, 2014

Looping back on this thread. My head has been in a very revenue & runway
orientated place lately, so sorry for silence, but this is incredibly cool,
and I've added full integration with this API to my tasks for the next
couple of days.

I really appreciate it. More once integration is complete.

Ben

On Sun, Oct 19, 2014 at 10:46 PM, Ryan Barrett notifications@github.com
wrote:

interesting! definitely a good consideration.

I might push back a bit, though. it is a nontrivial addition, a new
dependency, and makes the URLs less inspectable/debuggable, and there's
arguably no meaningful threat right now.

maybe we wait to do it until if/when we add more sensitive parameters? I'm
happy to leave this open to help us remember.


Reply to this email directly or view it on GitHub
#240 (comment).

Ben Werdmuller
http://goog_1933028737
benwerd.com | werd.io

+1 (312) 488-9373

benwerd commented Nov 5, 2014

Looping back on this thread. My head has been in a very revenue & runway
orientated place lately, so sorry for silence, but this is incredibly cool,
and I've added full integration with this API to my tasks for the next
couple of days.

I really appreciate it. More once integration is complete.

Ben

On Sun, Oct 19, 2014 at 10:46 PM, Ryan Barrett notifications@github.com
wrote:

interesting! definitely a good consideration.

I might push back a bit, though. it is a nontrivial addition, a new
dependency, and makes the URLs less inspectable/debuggable, and there's
arguably no meaningful threat right now.

maybe we wait to do it until if/when we add more sensitive parameters? I'm
happy to leave this open to help us remember.


Reply to this email directly or view it on GitHub
#240 (comment).

Ben Werdmuller
http://goog_1933028737
benwerd.com | werd.io

+1 (312) 488-9373

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Dec 24, 2014

Owner

closing for now since the bridgy side work is done. @benwerd, feel free to reopen if we discover more to do when you integrate. happy holidays!

Owner

snarfed commented Dec 24, 2014

closing for now since the bridgy side work is done. @benwerd, feel free to reopen if we discover more to do when you integrate. happy holidays!

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Feb 20, 2015

We just pushed this into core. However, the links don't seem to be working right now?

Still, awesome.

benwerd commented Feb 20, 2015

We just pushed this into core. However, the links don't seem to be working right now?

Still, awesome.

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 20, 2015

Collaborator

whoa awesome, benwerd++

and also which links aren't working?

Collaborator

kylewm commented Feb 20, 2015

whoa awesome, benwerd++

and also which links aren't working?

@kylewm kylewm reopened this Feb 20, 2015

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Feb 20, 2015

I'm actually testing with my localhost domain idno.dev, so I was also using:

https://brid.gy/twitter/start?feature=listen&callback=http%3A%2F%2Fidno.dev%2Faccount%2Fbridgy%2F

benwerd commented Feb 20, 2015

I'm actually testing with my localhost domain idno.dev, so I was also using:

https://brid.gy/twitter/start?feature=listen&callback=http%3A%2F%2Fidno.dev%2Faccount%2Fbridgy%2F

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 20, 2015

Collaborator

You actually have to use https://www.brid.gy ... it's some App Engine limitation.

Collaborator

kylewm commented Feb 20, 2015

You actually have to use https://www.brid.gy ... it's some App Engine limitation.

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Feb 20, 2015

Aha. We have the same requirement on our hosted service (to do with CNAME rules and dynamic IPs).

Made those changes and it appears to work like a charm!

benwerd commented Feb 20, 2015

Aha. We have the same requirement on our hosted service (to do with CNAME rules and dynamic IPs).

Made those changes and it appears to work like a charm!

@kylewm

This comment has been minimized.

Show comment
Hide comment
@kylewm

kylewm Feb 20, 2015

Collaborator

Phew, glad it was that easy. Congrats on the feature, looking forward to seeing it in action!!

Collaborator

kylewm commented Feb 20, 2015

Phew, glad it was that easy. Congrats on the feature, looking forward to seeing it in action!!

@kylewm kylewm closed this Feb 20, 2015

@benwerd

This comment has been minimized.

Show comment
Hide comment
@benwerd

benwerd Feb 20, 2015

Thanks for building such a simple interface!

benwerd commented Feb 20, 2015

Thanks for building such a simple interface!

@snarfed

This comment has been minimized.

Show comment
Hide comment
@snarfed

snarfed Feb 20, 2015

Owner

yay, excited to see this go out. nice work guys!

Owner

snarfed commented Feb 20, 2015

yay, excited to see this go out. nice work guys!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment